Architecture, posture inheritance, and the freeze.

From charter to architecture: the hand-off CORE

The charter answers what the system is. The architecture answers how the system works. The hand-off between the two is a discipline: no claim appears in the architecture that was not present in spirit in the charter, and no claim in the charter is left without an architectural consequence. If the charter says “the research agent reads public web sources,” the architecture says which tool runs that read, which prompt it uses, which rate limit governs it, and where the sources land on disk. If the charter says “a scheduled summary fires every Sunday evening,” the architecture says which scheduler invokes the summary, what time zone the cron expression is in, and which shared-state file the summary writes to.

The discipline matters because architectures written in isolation from their charters tend to drift toward whatever the student has been reading about most recently. A student who just watched a tutorial about vector databases may add a vector store to the architecture that the charter never asked for. A student who was frustrated by slow local inference may add a cloud fallback the charter did not authorize. These drift moves are not wrong in the abstract; they are wrong here, because they enlarge the system past what the charter committed to. The rule for Lesson 10.2 is that architecture changes that enlarge the system require a charter amendment, and charter amendments are written, signed, and dated. An architecture that quietly adds a component the charter never described is an architecture the rubric will catch and the reviewer will flag.

The architecture document is the second-longest frozen artifact in the capstone folder — three to five pages, depending on how much detail each component demands. It is longer than the charter because the level of specificity is different: the charter commits to what; the architecture commits to the mechanical how. A student who writes an architecture the same length as the charter has either written a too-long charter or a too-short architecture. The middle length is the right one.

The architecture is also the document Claude Code, Cowork, or any coding agent will read in Lesson 10.3 as the build spec. A well-written architecture can be pasted into a fresh coding-agent context and will produce component skeletons that match the charter. This is not the primary purpose of the architecture — the primary purpose is human clarity — but it is a useful secondary test. An architecture that a fresh agent cannot turn into sensible scaffolding is probably an architecture a fresh student cannot either.

The six sections of the architecture CORE

The architecture document has six sections. The shape is prescriptive so the parent-facing rubric can check each section against a named evidence-block, and so the reviewer can compare this architecture to one the student writes later (for a project after the course) with minimal re-orientation.

Section 1 — Inventory. A table of components. For each: the name (carried over from the charter), the shape (one of the four from Lesson 10.1), the tool it runs on (Claude Code, Cowork, a cron job, a shell script, a scheduled task on a local box), the invocation mode (scheduled / on-demand / triggered-by-another-component), and the data class it touches (public / personal / sensitive). The inventory is the index the rest of the architecture refers back to.

Section 2 — Data flow. A prose-plus-diagram section describing how data moves through the three components. Which component produces what; which component consumes what; where shared state lives (a folder on disk, a database table, a message queue, a single markdown file the student appends to). The diagram is a simple box-and-arrow drawing; the prose names the format of each arrow (markdown file / JSON file / SQLite row / HTTP POST / function call).

Section 3 — Trust boundaries. Carried forward from Section 3 of the Module 9 posture document, with a capstone-specific refinement: every arrow in the data flow diagram that carries text from an untrusted source — the open web, an inbox, a stranger’s file, an upstream component that itself read untrusted text — is marked as a trust boundary. The section lists each boundary and the hardening at each. If a boundary is new (the capstone’s data-flow pattern introduces a trust edge the Module 9 posture did not consider), the student amends the posture document and notes the amendment in this section.

Section 4 — Schedule and cadence. Every component’s schedule. Scheduled components name their cron expression (or the scheduling-tool equivalent), the time zone, and the expected wall-clock invocation pattern (“Sundays at 18:00 local, weekly”). On-demand components name their invocation pattern (“student runs this Monday mornings after the weekly planner component has written to shared state”). This section is also where the kill-switch mechanism lives: one command or UI action that halts every scheduled component at once.

Section 5 — Pre-flight cost estimate. Inheriting the Module 8 format: per-invocation cost for each component, per-day total, per-week total for the seven-day observation window. The estimate is first-pass — it will be revised in Lesson 10.3 when the student actually runs a component — but it needs to be defensible in one paragraph now. The section ends with a one-sentence verdict: “This estimate fits within the monthly budget of \$X with ~\$Y/month headroom,” or, if it doesn’t, the charter-amendment note that records the scope change needed to make it fit.

Section 6 — Posture inheritance. A one-paragraph statement that the Module 9 posture document governs the capstone, followed by any posture-specific amendments (for a new trust boundary, a new secret, a changed data class, a new rotation cadence). If there are no amendments, the paragraph says so. This section is the evidence the rubric uses to check that the capstone is actually operating under a posture, not adjacent to one.

A good architecture fits in three to five printed pages. Shorter than three pages is almost always too thin to guide the build; longer than five is almost always a document that is trying to substitute volume for precision. If the student is tempted to write a sixth section, the right move is to tighten one of the six existing ones.

Drawing the system diagram CORE

The diagram is not optional, and it is not fancy. A simple box-and-arrow drawing on paper, photographed into the architecture file, is fine. A whiteboard snapshot is fine. A diagramming tool’s output pasted in as an image is fine. What is not fine is an ASCII-art block that the student spent forty minutes formatting; the time-to-value ratio is wrong and the ASCII is harder to read than a photo of a notebook page.

Three boxes (or more), one per component. Arrows between boxes, with labels naming the data type crossing each arrow. Arrows to and from the outside world (the open web, the mailbox, the student’s local folder, the calendar) labeled with the data class. Trust boundaries marked as a thick line across any edge where untrusted text enters. The kill switch’s scope marked as a dotted outline around the components it halts.

The diagram’s purpose is to be looked at by the student and the reviewer before the build. A student who cannot draw the diagram without going back to the charter to check something has not yet internalized the design. A reviewer who cannot follow the diagram in ten seconds will not be useful as a reviewer.

A second purpose of the diagram is the demo video in Lesson 10.5. The video’s second beat — “here is what the system looks like on paper” — is the diagram. A diagram drawn in Lesson 10.2 is a diagram the student does not need to redraw for the demo. Keep the diagram file accessible in the capstone folder; name it system-diagram.png or equivalent.

A third purpose: the diagram is what the reviewer will use to decide whether to sign off in Lesson 10.5. The sign-off asks whether the reviewer would trust the system to operate unattended under its posture, and a diagram that does not clearly show the trust boundaries and the kill switch is a diagram the reviewer cannot evaluate.

Posture inheritance and what it means CORE

The Module 9 posture document governs the capstone. That is the starting claim and most of the work. The six sections of the posture — threat model, data classification, trust boundaries, secrets, cost, incident loop — apply to the capstone without revision unless the capstone’s architecture introduces a specific new thing the posture did not consider.

The three most common “new things” the capstone introduces:

The first is a new trust boundary. A capstone that adds a research agent reading a feed the posture did not mention has a new trust boundary at that feed. The posture is amended to include it; the architecture’s Section 3 names both the new boundary and the posture amendment.

The second is a new secret. A capstone that calls a third-party API the posture did not mention introduces a new key the student must store according to the Module 9 secrets posture. The key goes where keys go (environment variable, OS keychain, provider vault); it does not appear in the architecture document; the posture is amended to record its rotation cadence and scope.

The third is a new data class flow. A capstone that routes sensitive data the posture did not previously contemplate — the student’s own health notes, a household member’s information, a friend’s trust — gets a data-class amendment to the posture. The new flow runs on the local model per the Module 9 rule, or it does not run at all.

Most capstones introduce at most one of these. A capstone that introduces all three has a posture document doing too much work in Lesson 10.2 — the student is better served taking a day, writing the amendments formally, and re-running Lesson 9.5’s incident drill against the amended posture before returning to Lesson 10.2. The posture is the operating contract; changes to it are not casual.

A posture that does not need amendment is the better outcome. A capstone whose architecture fits inside the posture the student wrote before they knew what the capstone was is a capstone scoped well. If Section 6 of the architecture says “no amendments,” the student has demonstrated that their posture document was forward-looking enough to absorb the capstone — which is a strong signal about the quality of the Module 9 work.

The first-pass cost estimate CORE

A cost estimate at Lesson 10.2 is not a final number. It is a defensible first pass the student will sharpen in Lesson 10.3 once they have actually invoked each component once. The estimate is structured the same way the Module 8 pre-flight was — by component, by invocation, rolled up to the week — and the rule is the same: the student can defend each number in one sentence, or the number is a guess.

A worked example to model on. Consider a capstone with three components: a research agent that reads five public feeds each Sunday evening (shape 3), a coding agent the student invokes on demand each morning to process the research output (shape 2), and a custom skill that reformats the morning output to the student’s style guide (shape 4). The student’s rough estimate: the research agent runs five read-and-summarize cycles, each costing ~\$0.08 on the cloud model — \$0.40 per Sunday invocation. The coding agent runs once per day, uses ~\$0.25 of cloud per invocation on average — \$1.75 per week. The custom skill uses ~\$0.03 per run, once per day — \$0.21 per week. Total weekly cost ≈ \$2.36. Over seven days of the observation window, ~\$2.36. Over the month, ~\$10. Monthly budget per the posture: \$80. Headroom: ~\$70.

The estimate is defensible. The student knows where each number comes from. A \$2.36 weekly estimate that turns out to be \$4.50 when actually run is acceptable — the student adjusts in Lesson 10.3. A \$2.36 weekly estimate that turns out to be \$45 is a sign the estimate was pulled out of the air; the student returns to the charter and tightens.

The same worked example has a failure mode. Suppose the student’s research agent reads fifty feeds instead of five — because “more sources is better” crept into the design between the charter and the architecture. Per-invocation cost becomes ~\$4. Over four invocations per week (not one Sunday but every-other-day), the research cost alone is \$16/week, \$64/month — 80% of the monthly budget, with no headroom for the other two components. The architecture either gets a charter amendment to narrow the research agent, or the scope is cut. This is the kind of decision the cost estimate forces. An architecture without a cost estimate is an architecture where this kind of drift happens invisibly and surfaces as a surprise in Lesson 10.4.

Two practical notes. First, if a component runs against the local model instead of the cloud, its direct dollar cost is zero — but the time cost (local inference latency) is not, and the student notes that as a one-liner in the Section 5 verdict. Second, the provider’s hard cap from the posture is the safety net, not the estimate. A student who estimates \$10/month and has the hard cap set at \$80 has ~\$70 of cushion for legitimate surprises and catastrophic bugs alike. A student who estimates \$10/month and has no hard cap has neither.

Filling the template and freezing the file RECIPE

Create /capstone/capstone-architecture.md using the template from /resources/module-10/capstone-architecture-template/. The template has the six sections pre-skeletoned. Copy the charter’s Section 3 (components) into the architecture’s Section 1 (inventory) as the starting point, then fill each row with the additional fields the inventory needs.

Draw the diagram. Tool choice is the student’s. For most students the shortest path is: open a blank page in a note-taking app (Notes, Obsidian, a paper notebook photographed later), draw three boxes, draw arrows, label everything, export the image. Save the image as /capstone/system-diagram.png and link it from the architecture file under Section 2.

Walk the posture document. Open /capstone/security-posture.md side by side with the architecture. For each of the six posture sections, ask: does the capstone introduce anything this section did not already consider? If no, write “no amendment” in Section 6 of the architecture. If yes, write the amendment — one sentence per change — in the posture itself, re-date the posture’s Last reviewed field, and note the amendment in Section 6 of the architecture. The format is the same amendment-and-re-date pattern the posture document has used since Module 9; there is no new tooling.

Run the cost estimate. The Recipe Book entry pre-flight cost estimate for a pipeline (from Module 8, still current) carries the math; the capstone’s estimate is the same format. If the estimate is over budget, the charter is amended and Lesson 10.1’s revision is re-run before Lesson 10.3 begins.

Freeze the file. The architecture freezes at lesson end — which means the top of the file gets a Frozen: YYYY-MM-DD date stamp and a one-line commitment, and the file is considered the binding design for Lesson 10.3. Later amendments are marked with Amendment: <date> — <reason> entries at the bottom of the file, not silent edits. This is the same freeze header the charter carries in Lesson 10.1; no new format.

**Frozen:** 2026-04-18
**Author:** <your name>
**Reviewer:** <reviewer>
**Binding design for Lesson 10.3.** Amendments below this line are dated and signed.