Document, demo, and ship.

Why the shipping work matters CORE

A capstone that is not shipped is a capstone that does not close. A student who finishes Lesson 10.4 with a working pipeline and a clean observation log has done the hard technical work; what remains is the shipping work — the documentation, the demo, the reflection, the sign-off, the freeze. The temptation is to treat that work as optional or cosmetic. The course treats it as required, for three reasons.

The first is credit. The parent issuing one high school credit needs evidence. The course’s full ten-module arc, the capstone’s three-shape rule, the seven-day observation window — these are real, but they are evidence only if they are documented in a form a third party (the parent, a college admissions officer, a future employer) can read. The work produces the documents the credit argument rests on.

The second is closure. The course ends at the end of Module 10. A student who skips that work leaves the course in a liminal state: the work is technically done, but nothing marks the finishing. Students who skip closings on substantial projects tend to not finish subsequent projects either, because their sense of “what done feels like” was never built. That work is the moment the student can truthfully say they shipped something.

The third is the reviewer’s sign-off. The one-paragraph written sign-off from the reviewer is not a formality. It is the evidence that an outside observer — a mentor, a parent, a teacher, a technical friend — has watched the system run and would trust it to operate under its posture. The sign-off is what makes the student’s “my system works” claim externally verifiable. Without it, the capstone has no external referee.

Set aside a real block of focused time for it. The work splits into roughly four pieces — the consolidated final document, the demo video, the reflection and parent-facing paperwork, the sign-off exchange — plus some buffer for re-recording the demo or revising the reflection after a second read. Students who start with too little time often compress it into something the rubric will not pass. Block the time.

The final document: what goes in, what stays out CORE

capstone-final.md is the one document a reader can open to understand the whole system without navigating the rest of the folder. It is a consolidation, not a replacement — the charter, the architecture, the posture, the observation log, and the incident after-action remain as separate files — but it is the single starting point, and it is written to be read straight through in fifteen minutes.

Six sections, in this order:

Section 1 — What this system does

Two to three paragraphs, in the student’s voice, explaining the system for a reader who has not seen any of the other documents. The one-sentence purpose from the charter is here, expanded with context: what problem the student was trying to solve, why they cared, what the system does differently from doing the work by hand. This is the section the demo video’s opening beat is scripted from; write it first and record from it.

Section 2 — The architecture, summarized

One to two paragraphs plus the system diagram (the same system-diagram.png from Lesson 10.2, embedded here). The three components named by shape; the shared-state flow; the scheduler; the cost estimate’s measured verdict. A reader should be able to follow this section without ever opening capstone-architecture.md, even though the full architecture is still a click away.

Section 3 — The observation log summary

One paragraph summarizing the seven-day window: total runs per component, total cost vs. budget, any incidents (injection attempts caught, kill-switch fires, posture amendments). Plus a one-line reference to the full log in observation-log.md. This is the section the parent-facing rubric checks against.

Section 4 — Security posture summary

One paragraph naming the six sections of the posture document (threat model, data classification, trust boundaries, secrets, cost, incident loop) and stating that the capstone operated under it. Plus a one-line reference to security-posture.md. This is the section the reviewer’s sign-off rests on.

Section 5 — What would change next

Two or three sentences naming the single biggest improvement the student would make if they were starting over, and the next feature the student would add if the course continued. This section is a bridge between the reflection and the final document; it is a shorter, more public-facing version of the reflection’s fifth prompt.

Section 6 — Files in this folder

A short inventory of the capstone folder with a one-line description of each frozen file. This makes the folder navigable for any future reader, including the student’s own future self.

Appendices (after Section 6): the incident-drill after-action (incident-drill-afteraction.md contents inlined or linked), the observation log’s last-day summary (same treatment), and the demo video link. These are inlined-or-linked at the student’s preference; the rubric accepts either.

What does not go in capstone-final.md: the full text of the charter (it is one click away), the full architecture (same), the full posture (same), the full observation log (same), the full incident scenario (same), any discussion of that work itself (that belongs in the reflection). Conciseness is the discipline.

The demo video, five beats CORE

The demo video is 3 to 5 minutes. It is screen-recorded — the student’s screen plus microphone narration. No face-cam is required (though it is permitted). No video editing beyond trimming the head and tail. The first take that satisfies the five beats is the take that ships.

The five beats, in order:

Beat 1 — What this is, in one sentence (15–25 seconds)

“This is the capstone I built for AI Architect Academy; it summarizes my open tabs every Sunday evening and turns them into a one-page reading plan for the week.” The beat is 15 to 25 seconds. The student’s one-sentence purpose from the charter is the script.

Beat 2 — One real end-to-end run (60–120 seconds)

Fire the pipeline (or the on-demand trigger; if the scheduled cadence does not line up with the recording, pick the trigger manually). Watch the pipeline do its work in real time — or if real time is too slow, narrate what would happen and show the output that was produced in the last cadence. 60 to 120 seconds. The three components appear on screen as files change, logs update, and outputs land in the shared-state folder. The student names each component by its charter name as it fires.

Beat 3 — The intentional failure and the recovery (45–90 seconds)

The student does one thing on purpose that should trigger the incident loop — fires the kill switch, submits a test injection input, cuts a dependency. Narrate while doing it: “Here I’m firing the kill switch to show how the pipeline halts.” Show the components halting. Show the recovery: re-enable, observation log updated, life continues. 45 to 90 seconds. This is the beat that proves the system is operated, not just running.

Beat 4 — The posture check (~30 seconds)

Thirty seconds naming the three most important posture facts: data classes and routing (where the sensitive stuff runs), the monthly budget and hard cap, the reviewer who signs off. “This system processes only public and personal data; sensitive data stays on my local model. It runs under a $80/month budget with a $120 hard cap. My reviewer reviewed the demo video and posture before I shipped.” On-screen: a brief view of the posture document or Architecture §6.

Beat 5 — What I would build next (15–30 seconds)

Fifteen to thirty seconds. One sentence on what the student would add or change next, and one sentence on what they would need to learn to do it. “Next I’d add a second research agent specializing in primary-source historical documents, which would require learning how to handle OCR quality differences — that’s the skill I’d pick up first.” Then stop recording. The student does not summarize or thank anybody; the video ends when the content ends.

Total: ~3 to 5 minutes. Students who come in over 5 minutes almost always have too much Beat 2 — they narrated every component’s output in detail instead of letting the screen do the work. Edit the middle if needed; the opening and closing beats are load-bearing.

The video’s audience is the parent, the reviewer, the student’s future self, and the rubric reviewer. It is not optimized for a public audience. Students who choose to publish the video past the course do so outside the course’s audience rule; nothing prevents it, but the course does not advise it.

The reflection: five prompts, three-to-five sentences each CORE

The capstone reflection is not a free-form write-up. It is five specific prompts answered briefly. The shape is prescriptive because the shape of the reflection matters for parent credit documentation: a reflection that touches these five prompts is a reflection an admissions officer or employer can read and understand. A reflection that drifts is a reflection whose argument is harder to verify.

1. Prompt 1 — The hardest moment. Not the hardest topic — the hardest moment. A specific day, a specific bug, a specific dead end across the ten modules or the capstone build. Name what made it hard, and name what got you out (a person, a doc, a reread, a walk, a restart). Three to five sentences.
2. Prompt 2 — The surprise. One thing about directing AI systems that you did not believe (or did not see) before this course, and that you now believe (or see). “Surprise” means you would have been wrong if asked at the start. Three to five sentences.
3. Prompt 3 — The module that carried the most weight. Of Modules 1–9, which one contributed most to the success of your capstone? Be specific about what from that module actually showed up in your build — an architecture section, a smoke test, a posture amendment, a component design. Three to five sentences.
4. Prompt 4 — The module you underused. Of Modules 1–9, which one did you use least? Then the harder question: is that a gap in your work, or a signal that your capstone was correctly scoped away from that module’s concerns? Both answers are legitimate; the point is that you noticed. Three to five sentences.
5. Prompt 5 — What would you build next. Not “v2 of this capstone.” A new thing. Given what you can now direct, what is the next system you would build if you had another month? One-sentence name, problem it solves, shape of its three components, the single posture question it raises. Three to five sentences.

Total reflection length: roughly one printed page. Students who come in at half a page usually skipped Prompt 1 or 5 — the two prompts most likely to produce vague answers. Students who come in at three pages usually used the reflection to complain or celebrate; the prompts are answerable in the range the lesson specifies, and exceeding it is a sign the student is writing a different document. The operational debrief — what a run cost, what broke and which rail caught it, what posture amendment the capstone produced — belongs in capstone-final.md Section 6 and in the observation log’s end-of-window summary, not in the reflection. The reflection is more meta: it is where the student looks at the ten modules and the capstone as a system.

The reflection is the artifact most likely to shift how a future reader thinks about the student. A good reflection shows judgment, honesty, and ambition; those are rarer in student work than technical correctness, and they are what parents most want documented. Write it carefully.

The parent or peer reviewer sign-off CORE

The reviewer watches the demo video (or, if they and the student prefer, sits through a live walk-through of equivalent length), then has a short conversation with the student and records their answers to three questions: Does the system do what the charter says it does? Would you be comfortable operating it yourself under the posture? What would you change before v2? The answers are saved as /capstone/named-human-signoff.md using the template at named-human-signoff-template.md.

The answers do not need to be flattering. A sign-off that says “Yes, it does what the charter says; yes, I’d operate it; for v2 I’d add a second research agent for historical documents” is exactly the right shape. A sign-off that is pure praise is less useful than a sign-off that names a real observation. The third question is not a gate on sign-off — a v1 does not need to implement v2 feedback — but a non-trivial answer is a compliment, not a veto.

If the reviewer declines to sign — they watched the demo and do not believe the system would operate safely unattended, or they saw something in the posture they cannot endorse — the capstone does not freeze. The student talks with the reviewer, makes the change the reviewer flagged, and re-records the demo video if needed. A named-human-declined sign-off is a rare but important signal; the course’s whole point of having a reviewer is that this signal exists.

Most reviewers sign within 24 hours of receiving the video. If the reviewer goes more than three days without responding, the student follows up once; if another three days pass, the student picks a new reviewer and updates the posture document. This is the rare case the course’s setup needs a workaround, and the lesson names it explicitly so students are not stuck.

The sign-off is the course’s final external checkpoint. After it, the student freezes.

Freezing the capstone folder and closing the course RECIPE

The freeze sequence is short. Run through this checklist in order; the order is what makes it reliable.

1. Step 1 — Confirm the parent-facing rubric passes. Open /capstone/capstone-rubric.md. Walk the fifteen pass/fail criteria in order; confirm each one has its evidence artifact and the artifact meets the standard. If any criterion fails, fix it before continuing.
2. Step 2 — Confirm every frozen file has the freeze header. The charter (10.1), architecture (10.2), final document (10.5), and reflection (10.5) each have the standard freeze header at the top (date, author, reviewer, binding statement).
3. Step 3 — Update the credit documentation. Open /ops/credit-documentation.md — the course-level parent-facing document — and fill in the student-specific fields: total hours from the hours log, the transcript line the parent chose, the chosen letter grade (if any), and the portfolio list. This is the document the parent prints and keeps in the student’s homeschool credit records.
4. Step 4 — Commit everything to git, tag the commit. The tag is capstone-frozen-YYYY-MM-DD. A frozen capstone has a stable git revision any future reader can check out.
5. Step 5 — Write the closing note. In my-first-loop.md (the journal file that started in Lesson 1.5 and has accumulated reflections across all ten modules), write one paragraph: today’s date, a sentence on how the capstone feels, a sentence on what comes next. The course is done when this paragraph is written.
6. Step 6 — Tell the reviewer, your parent (if different), and anyone else you promised to tell. The freeze is a real thing that happened; people who have been following along want to hear that it happened. This is also the moment many students feel the completion in a way the earlier steps did not quite land.