Why the charter comes before the build CORE
The most common failure mode on an ambitious student capstone is not that the student builds the wrong thing. It is that the student builds an evolving thing — a project whose definition changes every few days, whose three components become five and then two, whose audience slides from “only me” to “also my family” to “also my friend’s family,” whose cost estimate nobody recomputes after the scope grew. The system that ships under those conditions is not the system the charter described; the system that ships is whatever the student happened to be working on in the last seventy-two hours. That system does not pass the rubric because the rubric is measuring something specific, and the thing the student built is no longer that specific thing.
The charter is the cure. It is a short document — one to two pages, written in the student’s own voice — that states, in the present tense, what the system is, who it serves, what shape each of its three components takes, what data classes it touches, and what it explicitly will not do. The charter is written in Lesson 10.1 and frozen at lesson end. Freeze does not mean “will never change” — a capstone that encounters a real constraint in Lesson 10.3 may need a charter amendment, and the course allows that with a written rationale. Freeze means changes are decisions, not drift. A capstone that amends its charter twice during Module 10 is a capstone in real conversation with reality; a capstone that amends its charter five times is a capstone that never picked a thing to build.
The charter’s tightness is itself part of the lesson. A student who cannot state in one sentence what the system does has not yet scoped the system. A student who cannot list, in one paragraph, the data the system will refuse to touch has not yet thought about security. A student who cannot name each of the three components by shape has not yet internalized the agentic vocabulary the course taught them. Lesson 10.1 is the enforcement point; the HTML activity at the end of the lesson is the gate. A charter that does not pass the gate is revised before the student moves on.
The charter is also the document the reviewer from Module 9 reads first. The reviewer is not reading the code — they cannot tell from the code whether the student has overcommitted. They are reading the charter, comparing it to their sense of the student, and flagging anything that sounds out of reach. A charter a reviewer cannot evaluate in ten minutes is a charter that is too long or too vague. Tight writing is a safety primitive.
The audience rule, applied to the capstone CORE
Every previous module has some version of the audience-equals-you rule. Module 10 is the module where the rule decides whether the capstone passes or not, because the capstone is the first system the student has ever operated for a full week under their own posture, and the audience rule is what keeps that week tractable.
The rule for Module 10 is strict: the capstone delivers output to its student-operator and to no one else. “Delivers output” means a human or service outside the student’s household reads, receives, processes, or acts on something the pipeline produced. Not “the draft sits in a folder the student reviews” — that is fine, audience is the student. Not “the summary lands in the student’s own email inbox” — that is fine, audience is the student. But “the summary auto-posts to a Discord channel my study group uses” is not fine — that is publishing, and publishing changes the threat model. “The calendar event the scheduler creates shows up on my shared family calendar” is a gray area that becomes clear when the student asks: if an injection attempt sneaks a malicious event in, does it land on someone else’s screen? If yes, that is publishing.
Three kinds of would-be-publishing seem harmless and are not:
- Auto-replying. A research agent that drafts an email to an outside correspondent and sends it without the student reading first is publishing, even if the outside correspondent is someone the student knows well. The student’s name is on the reply and the student did not review it.
- Cross-household calendar writes. A calendar agent that places events on a calendar other people read is publishing. The student may be the only person who sees the calendar normally, but if another human can see it, the event is public for the purposes of Module 10’s rule.
- Public-by-default writes to any networked service. A Slack / Discord / public-Trello / shared-Notion write is publishing. The absence of a second human in the room when the agent writes is not the same as the absence of a second human in the audience.
The rule is not a moral claim about what students should or should not build long-term. It is a scoping claim about what fits in this course: a one-student system is a tractable threat model, and an audience that expands beyond the student is a threat model that needs more than the course teaches. Students who want to build something public are welcome to, after the course, with a different posture document. Module 10 itself is a one-audience system.
If the charter’s description of the system is read honestly and the audience rule is broken, the charter does not pass the scope check. The student rewrites. The most common way to rewrite is to move the outbound action inside a manual step: the pipeline drafts, the student reviews, and the student (not the pipeline) sends. A rubric-passing capstone can absolutely include a draft-an-email component — it cannot include an auto-send-an-email-to-anyone-but-the-student component.
The four agentic shapes CORE
A capstone with three integrated components does not automatically demonstrate integration. Three components that are really three versions of the same thing — three scheduled summaries, each reading a different feed — demonstrate parallelism, not integration. Integration means three components with meaningfully different work coming together under one posture. The course’s vocabulary for “meaningfully different” is the four-shape frame. The shapes come from the modules the student already lived through; they are not new.
Shape 1 — the scheduled or automated agent. A program that fires on a clock or an event — a daily summary, a weekly report, a threshold alert, a monitor. The work happens without the student’s ongoing attention. Module 6 built this shape. Student examples: a daily digest that pulls headlines from three feeds and writes one page of notes; a weekly “open tabs” reviewer that triages bookmarks; a cost monitor that checks the student’s own spending against the budget from Module 9 and alerts if trending over. Characteristic signature: time-triggered, produces an output the student reads after the fact, needs a kill switch.
Shape 2 — the coding or build agent. A program run on demand that reads code or text and produces a code or artifact change under the student’s direction. Module 3 built this shape. Student examples: a Claude Code setup that refactors the student’s own note-taking repo; a Cowork agent that reads a directory of meeting-prep notes and produces a single-page slide outline; a skill-runner that iterates on the student’s essay-in-progress against a rubric. Characteristic signature: invoked deliberately, produces a diff or file, benefits from review before acceptance.
Shape 3 — the research or inbox agent. A program that reads text from the open web, a mailbox, a calendar, or a document collection — text the student did not write — and produces a structured output the student reads. Modules 4 and 5 built this shape. Student examples: a research agent that gathers sources for a school paper and produces a source map with confidence notes; an inbox triage agent that tags and summarizes incoming email, leaving drafts for review; a calendar briefer that produces the week’s commitment digest. Characteristic signature: consumes untrusted text, the highest-injection-risk shape, the one most constrained by Module 9 posture.
Shape 4 — the custom skill or plugin the student wrote. An extension to one of the course’s platforms that the student themselves authored. Module 7 built this shape. Student examples: a Claude Code skill that reformats the student’s research output to a personal style guide; a Cowork plugin that wraps a small utility the student uses often; a slash-command the student invokes from a coding agent. Characteristic signature: the student is both author and user, the extension lives in /capstone/skills/ or the equivalent, the plugin register from Module 7 is where it is documented.
A passing capstone uses three of these four shapes, not three instances of one. A capstone that uses a scheduled summary, a scheduled digest, and a scheduled alert has one shape repeated three times — it does not pass. A capstone that uses a scheduled summary, a research agent that feeds the summary, and a custom skill that reformats the summary has three distinct shapes composing under one posture — it passes on the shape axis.
The shapes are not a straitjacket. A capstone that wants a fourth component in a fourth shape is welcome to. A capstone that uses shape 1 and shape 3 for two of its components and wants to use shape 2 and shape 4 for a single combined third component (a custom skill that wraps a coding agent, for instance) is also welcome — the rule is three components covering three different shapes, not three components that each belong to exactly one shape. The shape rule is a minimum-diversity rule; it is not a taxonomy the student has to defend in court.
The realism filter CORE
A charter that passes the audience rule and the shape rule can still be the wrong charter because it is unrealistic. Realism on a capstone has three axes, and the charter names where it sits on each.
Time. The capstone has whatever block of time the student and their parent or instructor have agreed to set aside across the five lessons. The charter lists each component with a one-sentence budget estimate, and the estimates sum within that agreed window. A student whose charter estimates a build effort that does not fit the agreed window has either underscoped their skill level or overscoped their ambitions; either way, the charter is rewritten.
Cost. The capstone runs live for seven days under the Module 9 monthly budget. A research agent that makes a hundred cloud-model calls per run, scheduled three times a day, for seven days, is 2,100 cloud calls in a week — which is either fine or catastrophic depending on the per-call cost the student does not know yet. The charter does not demand a final cost estimate, but it demands a first-pass estimate that the student can defend in a sentence. The Module 8 pre-flight format is the template; the full estimate is finished in Lesson 10.2.
Data. The Module 9 data-classification rule (public / personal / sensitive) applies. The charter names, for each component, the highest-class data that component touches. A research agent consuming public sources is fine; an inbox triage agent touching personal email is fine under the cloud-model rule; a skill that summarizes the student’s health notes is a sensitive-data flow and routes to the local model. A capstone whose data classes are mis-routed fails Lesson 10.2’s architecture review. The charter catches the problem early.
A realistic charter is one where a student who is rested, who has the time set aside for Module 10, and who did not skip prior modules, could plausibly ship the system in the remaining four lessons. A rule of thumb: if the student would need to work substantially more time per day than the agreed Module 10 window allows, the charter is overscoped. Cut a component; pick a narrower problem; swap a harder shape for an easier one. Ambition is welcome after the course.
What a passing charter looks like CORE
A strong Module 10 charter is structured around six short sections. The prescriptive structure is the point: it is what makes the charter easy for the reviewer to read, easy for the student to pressure-test against the HTML activity, and easy to compare against the architecture document in Lesson 10.2.
- Section 1 — One-sentence purpose. What does the system do? Written for a reader who has never heard of the student’s life. “My capstone summarizes my open tabs every Sunday evening and produces a one-page weekly-reading plan for the upcoming week.” That kind of sentence.
- Section 2 — Audience. One sentence. Names the student as the sole consumer. Explicitly states what the system does not do — auto-send, auto-post, cross-household writes, the specific temptation the student had in mind when they wrote this section.
- Section 3 — Components. A numbered list of three (or more; three minimum). For each component: its name (the student’s own name for it), its shape (one of the four), its one-sentence job, and the tool it runs on (Claude Code, Cowork, a cron job, a local script — whichever).
- Section 4 — Data. For each component, the highest data class it touches and the routing rule that follows. A sensitive-class component is local-only; a personal-class component may use the cloud model per Module 9; a public-class component has no routing constraint.
- Section 5 — Out of scope. A numbered list. The public-output aspirations the student explicitly rejected. The tools the student considered and decided not to use. The features the student postponed to “after the course.” Three to seven items.
- Section 6 — Signature. Student’s name, date, reviewer (the reviewer), and a one-line commitment: “I will operate this system for seven consecutive days under the Module 9 posture before freezing.” The signature is not legalese; it is the student reading their own commitment back to themselves.
A passing charter fits on one printed page if the student writes tightly and up to two pages if they need the room. Three pages is too long; the charter has become a design document, and the design document is Lesson 10.2’s work.
Creating the charter file and passing the scope check RECIPE
This is the only recipe block in Lesson 10.1. The detail is concrete because the charter needs to live in a known place from this lesson on.
Create /capstone/capstone-charter.md in the same /capstone/ folder where every other frozen artifact lives — my-first-loop.md, the Module 2 workstation manifest, the Module 7 plugin/skill register, the Module 8 pipeline blueprint, the Module 9 posture document. The template lives at /resources/module-10/capstone-charter-template/ and is worth copying into the capstone file at the start so the six sections are pre-skeletoned.
After a first-pass fill, run the HTML activity at Capstone scope check. The activity walks through seven yes-or-no questions against the charter the student just wrote. A capstone charter needs seven yeses to pass. The questions are, in order:
- Does the one-sentence purpose fit on one line and describe what the system does, not how?
- Does the audience section name you and only you?
- Do the three components cover at least three different shapes?
- Is each component tagged with a tool that exists today?
- Is the data-class routing consistent with the Module 9 rule (sensitive = local, not cloud)?
- Does the out-of-scope section explicitly reject a public-output aspiration, even a small one?
- Would a rested student with the time set aside for Module 10 plausibly ship this in four lessons?
The activity does not grade the charter; it surfaces the failure modes. A charter that gets a “no” on any question is revised. Most students need one or two revision passes; students who get all seven yeses on first try often turn out to have an overscoped charter masquerading as an underscoped one, and are asked to re-run the activity after writing down a more ambitious version of each component to stress-test. The activity is a conversation with the charter, not a quiz.
The charter template and the HTML scope-check activity are the two tools the student leans on here. This lesson’s job is to make sure the student can use both together.
Try it — Write and test the capstone charter CORE
deliverables: frozen /capstone/capstone-charter.md, the Capstone scope check activity passed with 7/7, one paragraph naming what you cut during revision
Part 1 — Create the file.
Create /capstone/capstone-charter.md using the capstone charter template. Fill the date and signature placeholder (reviewer will be filled when you share with your reviewer).
Part 2 — Draft the charter.
Work through the six sections in order. Resist the urge to write the one-sentence purpose last; writing it first forces the rest of the document to be consistent with it. If you cannot write the purpose in one sentence, the system is not yet scoped and the rest of the charter will drift.
Tip for Section 3 (components): write the shape before the name. A student who writes “component 2 — the thing that reads my email” has not yet committed to whether that is a research-or-inbox agent or a scheduled task that happens to read email. Picking the shape forces a decision about who invokes the component and when, which is the question the architecture document in Lesson 10.2 will answer in full.
Tip for Section 5 (out of scope): write at least one thing you actually wanted to include and talked yourself out of. The out-of-scope section that only lists things you never considered is the section that did not do real work. The out-of-scope section that names a real temptation — “I wanted the summary to auto-post to my study Discord; I rejected this because it is publishing and breaks the audience rule” — is the section that will save the student an argument with themselves in Lesson 10.4.
Part 3 — Run the scope check.
Open the Capstone scope check activity in a browser. It presents the seven yes-or-no questions. Answer each against your charter; the activity scores at the end. A score of 7/7 means the charter is ready for Lesson 10.2; a score below 7/7 means the charter is rewritten until the failing questions pass.
Most charters fail on Question 3 (three-shape rule) or Question 7 (realism). Charters that fail on Question 2 (audience) tend to fail it loudly — there is usually one specific cross-household write the student was excited about. If your charter fails Question 7, the most common revision is “cut the third component and rescope it as a Recipe Book entry for after the course.”
Part 4 — Write the revision note.
In your journal or my-first-loop.md, write one paragraph naming what you cut or changed during revision, and why. This paragraph becomes raw material for the reflection in Lesson 10.5. Cuts are not failures; cuts are the evidence that scoping happened.
If your charter is too abstract
A charter that reads “my capstone uses AI to improve my productivity” is not a charter — it is a label. Revise by naming the specific inputs (the tabs, the mailbox, the folder), the specific cadence (Sunday 6pm, every weekday morning, on demand), and the specific output format (one-page PDF, three emails in draft folder, a markdown file at a known path). A tight charter names the nouns.
Done with the hands-on?
When the recipe steps and any activity above are complete, mark this stage to unlock the assessment, reflection, and project checkpoint.
Quick check
Five questions. Tap a question to reveal the answer and the reasoning.
Show explanation
Answer: B. The charter is the decision point that turns “I will figure it out” into “I have committed to this shape.” (A) is circular — the rubric requires it because the course wants scoping to happen first, not the other way around. (C) is factually wrong — reviewers can and do review prototypes. (D) is not how the charter works; it is a written commitment, not a legal instrument.
Show explanation
Answer: A. Shape 1 (scheduled), shape 2 (coding agent), shape 4 (custom skill) — three different shapes, three components, passes the rule. (B) misreads the rule: integration between components is required, not forbidden; sharing input is integration. (C) is not the rule. (D) is the inverse of what the course teaches — integration is the hard part, not independence.
Show explanation
Answer: B. The out-of-scope section’s job is to document decisions, not rehearse boilerplate. An entry that names a temptation and rejects it for a reason is doing real scoping; an entry that lists features the student never considered is filler. (D) is partially true in spirit — future-proofing against your own later temptation is a real benefit — but it is not the reason the lesson emphasizes the entry. (A) and (C) overstate the rubric’s specificity.
Show explanation
Answer: B. The realism filter runs on three axes; this charter fails two of them. The lesson’s response is to cut, narrow, or swap, not to accommodate. (A) and (D) accommodate; the posture exists specifically to resist that. (C) is a partial fix but does not address the time overrun, and it quietly changes the charter’s claim about cadence without a rationale.
Show explanation
Answer: C. First-try 7/7s are more likely to be under-scoped than perfectly calibrated. The lesson asks the student to stress-test with a more ambitious version before moving on, so the chosen scope is a real decision, not a default. (A) is reasonable but gives up the opportunity to check. (B) is always welcome but is not specific to this case. (D) misdiagnoses: the problem is not a missing component, it is that the student may be undersized rather than the charter.
Reflection prompt
Compare the Lesson 1.5 loop to the Lesson 10.1 charter
Write a short paragraph (4–6 sentences) in your journal or my-first-loop.md in response to the following: Go back to my-first-loop.md from Lesson 1.5 — the one-page capstone candidate you wrote at the beginning of the course. Compare it to the charter you just wrote. What is the same? What changed? Which change surprises you most — that the system got smaller and more focused, or that it got more ambitious in places you did not expect? If you were advising a student who was just starting Module 1, what would you tell them to write differently in their Lesson 1.5 draft so their Module 10 charter had less work to do?
The purpose is to make the arc legible. The capstone candidate from Lesson 1.5 was deliberately non-binding; the charter in Lesson 10.1 is the binding version. The distance between the two is the shape of nine modules of thinking.
Project checkpoint
By the end of this lesson, you should have: /capstone/capstone-charter.md created, with all six sections filled, in your own words; the Capstone scope check activity passed with 7/7 yeses (after as many revision passes as needed); one paragraph in your journal or my-first-loop.md naming what you cut during revision and why; and the name of your reviewer (your reviewer from Lesson 9.5) filled in the charter’s signature section, with a brief note to them — one paragraph in an email or message — asking for a read-through of the charter before you move to Lesson 10.2. Do not block on their response; they can reply by the end of Lesson 10.2.
Instructor / parent note
This lesson does two jobs. First, it imposes a charter-before-build discipline: the student writes and freezes a one-to-two-page document that commits the capstone to a specific shape before any code is written. Second, it introduces the three-shape rule — the minimum-diversity rule that distinguishes a capstone with real integration (three different shapes composing under one posture) from a capstone with apparent scale (three instances of the same shape).
Watch for two failure modes. The first is the student who writes a purpose-by-label charter — “my capstone uses AI to improve my productivity.” Walk them back to the concrete nouns: what is the input, what is the cadence, what is the output format. A charter that cannot name the nouns has not yet scoped the system. The second failure mode is the student who turns in a 7/7 scope-check score on the first try with a suspiciously narrow charter. Ask them to write a more ambitious version of each component as a stress test. Most first-try 7/7s are under-scoped, not perfectly calibrated.
Parent prompt for the read-through: “If I had to operate this system for a week while you were on a trip, would the charter tell me enough to know when to leave it alone and when to step in?” If the answer is no, the charter needs specificity. The charter is the first of four frozen capstone artifacts; getting it tight here saves work in every later lesson.
Next in Module 10
Lesson 10.2 — Architecture, posture inheritance, and the freeze.
You take the charter and turn it into a three-to-five-page architecture document: the six sections (inventory, data flow, trust boundaries, schedule, cost, posture inheritance), the system diagram, the posture amendments (if any), and the first-pass cost estimate. The architecture freezes at lesson end — the second frozen Module 10 artifact.