Capstone shape and scoping (Lesson 10.1)
- Capstone
- The integrated agentic system the student builds, operates, and ships in Module 10. It is the portfolio artifact of the course; everything frozen in Modules 1–9 supports it.
- Charter
- The 1–2 page document the student writes in Lesson 10.1 that names what the system is, who it serves, the three components by shape, the data classes it touches, and the explicit out-of-scope list. The first frozen Module 10 artifact (tenth overall, joining my-first-loop.md and the Module 2–9 freezes).
- Architecture
- The 3–5 page design document the student writes in Lesson 10.2 that turns the charter into a buildable spec — inventory, data flow, trust boundaries, schedule, cost estimate, posture inheritance. The eleventh frozen capstone artifact.
- Capstone-final
- The single-document fifteen-minute summary the student writes in Lesson 10.5 that consolidates charter, architecture, observation log, and posture into one starting point for any future reader. The twelfth frozen capstone artifact.
- Capstone-reflection
- The five-prompt, ~one-page reflection the student writes in Lesson 10.5. The thirteenth and final frozen capstone artifact.
- Audience = only you (capstone version)
- The Module 4–9 rule, applied strictly to the capstone. The pipeline delivers output to its student-operator and to no one else; auto-send, cross-household calendar writes, and public-by-default writes to networked services are all out of scope. The most common scope-check failure on Module 10's HTML activity.
- The four agentic shapes
- Module 10's vocabulary for "meaningfully different agent kinds": - Shape 1 — scheduled or automated. Fires on a clock or an event; produces output the student reads after the fact. Module 6 territory. - Shape 2 — coding or build. Run on demand; reads code or text and produces a code or artifact change under the student's direction. Module 3 territory. - Shape 3 — research or inbox. Reads untrusted text from the web, a mailbox, a calendar, or a document collection; produces a structured output the student reads. The highest-injection-risk shape. Modules 4 and 5 territory. - Shape 4 — custom skill or plugin. An extension the student themselves authored. Lives in /capstone/skills/ or the equivalent. Module 7 territory.
- The three-shape rule
- A passing capstone uses at least three of the four shapes, not three instances of one. Three scheduled summaries does not pass. Three research agents does not pass.
- The realism filter
- The capstone's three-axis check: time (sum of component build budgets fits in 28–32 hours), cost (first-pass estimate inside the Module 9 monthly budget), data (highest data class per component routes correctly). A charter that fails any axis is rewritten.
- Scope-check activity
- The seven-question HTML activity at /activities/module-10/capstone-scope-check.html that gates Lesson 10.1 → 10.2. A charter needs 7/7 yeses to pass. First-try 7/7s are stress-tested by re-running against a more ambitious version of the charter.
Architecture and posture inheritance (Lesson 10.2)
- Charter → architecture hand-off
- The discipline that no claim in the architecture lacks a charter predecessor, and no claim in the charter lacks an architectural consequence. Architecture changes that enlarge the system require a charter amendment with a signed rationale.
- The six architecture sections
- (1) Inventory — a table of components. (2) Data flow — prose plus diagram. (3) Trust boundaries — every untrusted-text edge, with hardening. (4) Schedule and cadence — cron expressions, kill switch. (5) Pre-flight cost estimate — per-invocation, per-day, per-week. (6) Posture inheritance — Module 9 amendments (or "none").
- System diagram
- A simple box-and-arrow drawing — three boxes, labeled arrows, trust boundaries marked, kill-switch scope outlined. Saved as /capstone/system-diagram.png and embedded in Architecture §2. The diagram the reviewer reviews and the demo video shows.
- Posture inheritance
- The Module 9 posture document (security-posture.md) governs the capstone without revision unless the capstone's architecture introduces a new trust boundary, new secret, or new data-class flow — the three common amendment triggers. Most capstones need at most one amendment.
- Posture amendment
- A dated, signed change to the posture document. Written into the posture itself with a re-dated Last reviewed line, then noted in Architecture §6. Not a casual edit — the posture is the operating contract.
- Pre-flight cost estimate (capstone version)
- The Module 8 format applied to the capstone: per-component, per-invocation, rolled up to per-week and per-month. Each number is defensible in one sentence. First-pass in Lesson 10.2; replaced with measured numbers in Lesson 10.3.
Build sprint (Lesson 10.3)
- Pipeline-v1
- The working folder /capstone/pipeline-v1/ that holds the actual running code. Subfolders per component, plus a shared-state/ folder, plus kill-switch.sh at the root. The folder is the running pipeline; the architecture document describes what the pipeline does.
- Isolation-first discipline
- The Lesson 10.3 rule that each component is built and smoke-tested as a standalone program before any wiring. Three components that ran alone yesterday integrate easily today; three components that have never run alone are nearly impossible to debug after wiring.
- Smoke test
- A tiny check that the component is alive — a single invocation against a known input produces a non-empty output at the expected path in the expected format. Not a unit test, not a correctness proof. The bar is "the program does not silently produce nothing useful." Three shape-specific patterns: scheduled (output file exists in time), coding (diff is the right kind of change), research/inbox (output cites the input and refuses instruction-shaped text).
- Architecture is the spec; drift is a charter amendment
- The discipline that no silent change happens during the build. Three amendment categories: - Narrowing amendment — the architecture overestimated; reduce scope. (Most common; pass without sign-off.) - Tool-switch amendment — a component is easier in a different tool than planned. (Pass without sign-off if posture implications check out.) - Postponement amendment — a component is larger than estimated; cut to post-course roadmap. (Pass; named in the reflection.) - Enlargement amendment — adding scope, widening data access, loosening an out-of-scope item. (Requires reviewer sign-off before proceeding.)
- Measured cost
- The cost estimate built from one real invocation of each component, replacing the Lesson 10.2 first-pass estimate. Within ±30% of the estimate is fine; over by 30% triggers architecture review; under by 80% triggers a check that the component is doing its work.
- Premature factoring
- The temptation to extract a shared helper into shared/ on day one because two components want to call it. The Lesson 10.3 rule: not yet. Duplicate the helper across components for a week; let the second use case shape the helper's design; factor in Lesson 10.4 if it is still worth it.
Integration and the seven-day window (Lesson 10.4)
- Shared-state pattern
- Components communicate through files at known paths in /capstone/pipeline-v1/shared-state/, not through direct function calls. Three benefits: legibility (bugs become visible as missing or malformed files), resumability (a halt mid-flight resumes from the last good file), and injection containment (a downstream component can refuse instruction-shaped content found in upstream output).
- Kill switch as a practiced ritual
- Module 6 introduced the kill switch as a documented object; Module 9 wrote it into the posture; Module 10 fires it on purpose, once, during Lesson 10.4, and records the measured halt and revert times in Architecture §4. A kill switch that has never been fired is a kill switch that may not work.
- Incident drill (capstone version)
- One of the four Lesson 9.5 scenarios — leaked key, runaway pipeline, drafted-but-unauthorized action, prompt injection that succeeded — executed end-to-end against the running pipeline. The four-step loop (stop / assess / repair / tell one human) runs against real machinery instead of documents. Produces a one-paragraph after-action note saved to /capstone/incident-drill-afteraction.md.
- Seven-day observation window
- The pipeline runs live for seven consecutive calendar days under the Module 9 posture, logged in observation-log.md. Long enough that scheduled components fire their natural cadences, that cost accumulates, and that at least one unanticipated thing happens. Short enough to fit inside Lesson 10.4. Calendar time, not invocation time — running components out-of-schedule to "catch up" is forbidden.
- Observation log
- /capstone/observation-log.md. One short block per day during the seven-day window: date, runs, cumulative cost, incidents, notes. Six to twelve lines per day. Backfilling is forbidden; the log is evidence the rubric and reviewer both check.
- Restart-on-failure rule
- A mid-window failure that violates the posture (sensitive data goes to cloud, kill switch fails, audience rule breaks, monthly budget breached) restarts the seven-day count from day one. Most students restart at least once; a third failed restart is a signal the architecture needs amendment, not more attempts. Restart is not punishment — it is what separates "ran okay for three days" from "ran cleanly for a week."
Ship and freeze (Lesson 10.5)
- The shipping ritual
- The non-optional five-step close: documentation (capstone-final.md), demo video (demo.mp4), reflection (capstone-reflection.md), reviewer sign-off (named-human-signoff.md), folder freeze. The ritual produces credit evidence and the closure that makes the course end.
- The six capstone-final.md sections
- (1) What this system does (2–3 paragraphs). (2) The architecture summarized (1–2 paragraphs plus the diagram). (3) The observation log summary (1 paragraph). (4) Security posture summary (1 paragraph plus reference). (5) What would change next (2–3 sentences). (6) Files in this folder (one-line inventory). Plus appendices (incident drill after-action, observation log last-day, demo link).
- The five demo-video beats
- (1) What this is, in one sentence (15–25 seconds). (2) One real end-to-end run (60–120 seconds). (3) The intentional failure and the recovery (45–90 seconds — the beat that proves the system is operated, not just running). (4) The posture check (30 seconds). (5) What I would build next (15–30 seconds). Total: 3–5 minutes. The video that comes in over 5 minutes almost always over-narrated Beat 2.
- The five reflection prompts
- (1) The hardest moment — a specific day, bug, or dead end across the ten modules. (2) The surprise — one thing about directing AI you would have been wrong about at course start. (3) The module that carried the most weight — which of Modules 1–9 contributed most, with the specific element that showed up in the build. (4) The module you underused — and whether that is a gap or a correct scoping decision. (5) What you would build next — a new system (not v2 of this one), with shape and posture question. Three to five sentences each. Operational debrief (cost, breakage, posture amendments) belongs in capstone-final.md §6, not the reflection.
- Named-human sign-off
- The one-paragraph written sign-off from the trusted person the student named in Lesson 9.5, after watching the demo or sitting through a live walk-through. Three required questions: Does the system do what the charter says? Would you be comfortable operating it yourself under the posture? What would you change before v2? Saved as /capstone/named-human-signoff.md. A declined sign-off means a real change before freeze.
- The fifteen rubric criteria
- The pass/fail evidence checklist in /capstone/capstone-rubric.md (parent-facing) and the EOM check Q7 (student self-rubric, identical fifteen criteria). Each criterion names the artifact the evidence lives in. The rubric passes when all fifteen pass.
- The optional 0–4 score appendix
- For households that need a letter grade for a transcript: each of the fifteen criteria scores 0–4, mapping to a letter grade (60 → A, 45–59 → B, 30–44 → C, below 30 → incomplete). Optional; the pass/fail rubric is authoritative.
- The six freeze steps
- Lesson 10.5's close-out checklist: (1) Confirm the parent rubric passes. (2) Confirm every frozen file has the freeze header. (3) Update credit documentation. (4) Commit and tag (capstone-frozen-YYYY-MM-DD). (5) Write the closing note in my-first-loop.md — the step students most often skip and the one that most reliably produces closure. (6) Tell the people who were following along.
Files in /capstone/ at end of course
- capstone-charter.md
- Frozen in Lesson 10.1. The 1–2 page commitment to what the system is, who it serves, the three components by shape, the data classes, and the explicit out-of-scope list.
- capstone-architecture.md
- Frozen in Lesson 10.2. The 3–5 page design document with six sections (inventory, data flow, trust boundaries, schedule and kill switch, cost estimate, posture inheritance) and the embedded system diagram.
- system-diagram.png
- Saved in Lesson 10.2 and embedded in the architecture's Section 2. The simple box-and-arrow drawing the reviewer reads first.
- security-posture.md
- Inherited from Module 9; amended in Lesson 10.2 if the capstone introduced a new trust boundary, secret, or data class.
- pipeline-v1/
- The working pipeline folder built in Lesson 10.3. Three component subfolders, a shared-state/ folder, a root README.md, a kill-switch.sh. Wired and observed in Lesson 10.4.
- incident-drill-afteraction.md
- Saved in Lesson 10.4 after walking one of the four scripted scenarios end-to-end against the running pipeline.
- observation-log.md
- Saved in Lesson 10.4 after seven consecutive clean calendar days under the posture. One short block per day; backfilling is forbidden.
- capstone-final.md
- Frozen in Lesson 10.5. The single-document summary that reads straight through in fifteen minutes. Six sections plus appendices.
- demo.mp4
- Saved in Lesson 10.5. A 3–5 minute screen recording covering the five beats. Audience is the student, the reviewer, and any future reviewer.
- capstone-reflection.md
- Frozen in Lesson 10.5. The five-prompt reflection (hardest moment, surprise, module that carried the most weight, module underused, what to build next).
- named-human-signoff.md
- Saved in Lesson 10.5 after the reviewer watches the demo and answers the three sign-off questions in their own voice.
- capstone-rubric.md
- The parent-facing fifteen-criterion rubric. Mirrors the sixteen-criterion student self-rubric in the Module 10 end-of-module check.