Capstone Architecture Template

Module 10, Lesson 10.2 · six-section operating design · produces /capstone/capstone-architecture.md

Save this as: /capstone/capstone-architecture.md. Freeze at end of Lesson 10.2.

Use it again: at the top of every build session in Lessons 10.3–10.4. Amendments go below Section 6 and at the end of the document, dated and signed.

Charter → architecture is disciplined.

No new claims without a charter predecessor; no charter claim without an architectural consequence. The charter is the what and who; this architecture is the how.

Header

Started: Frozen:

Charter reference:

/capstone/capstone-charter.md frozen on the date above.

Posture reference:

/capstone/security-posture.md last dated on the date above.

Section 1 — Components, in detail

One sub-block per component in the charter. Each answers the same six fields.

1.1 Component 1

Name:

Shape (tick one):

☐ scheduled/automated ☐ coding/build ☐ research-or-inbox ☐ custom skill/plugin

Trigger (what starts this component):

Inputs (what it reads, from where):

Outputs (what it writes, to where):

Model and routing (cloud / local; which data class goes where):

Failure mode (most likely failure and what happens then):

1.2 Component 2

Name:

Shape (tick one):

☐ scheduled/automated ☐ coding/build ☐ research-or-inbox ☐ custom skill/plugin

Trigger:

Inputs:

Outputs:

Model and routing:

Failure mode:

1.3 Component 3

Name:

Shape (tick one):

☐ scheduled/automated ☐ coding/build ☐ research-or-inbox ☐ custom skill/plugin

Trigger:

Inputs:

Outputs:

Model and routing:

Failure mode:

Section 2 — System diagram

One diagram, four required elements

Paste or sketch diagram here. Include: three component boxes, shared-state arrows with format labels, trust-boundary dashed outline, kill-switch scope.

Diagram file:

e.g., system-diagram.png, .svg, or .mmd.

Section 3 — Shared state

The contract between components

Without shared state, the components are three unrelated scripts. With it, they are a system.

Location:

Format:

Retention:

Access control:

Shared-state schema (one row per field):

Field	Written by	Read by	Data class	Notes
run_id	Component 1	Components 2, 3	public	ISO timestamp, used as filename

Section 4 — Kill switch

One command, one halt

If you cannot name it in one sentence, the system is not safe to operate.

Kill switch description (one sentence):

What it halts (components, schedules, in-flight work):

Target time-to-halt (committed):

How I’ll test it (in Lesson 10.4):

Section 5 — Cost, budget, and measured spend

Pre-flight estimate vs. measured reality

Monthly budget from posture: $

Metric	Pre-flight estimate (L10.2)	Measured (end of L10.4 window)
Cloud model spend (USD)
API spend (non-LLM)
Electricity / local compute
Projected monthly total

If the measured value exceeds the budget, name what you will change (reduce schedule, move a component to local, tighten prompt, remove a component):

Section 6 — Posture fit and amendments

6.1 Posture fit

For each posture element, confirm the capstone lives inside it. Tick the box if clean; write detail if not.

☐ Data classification

☐ Secrets

☐ Trust boundaries

☐ Network

☐ Cost

☐ Kill switch

6.2 Amendments (if any)

If any answer in 6.1 is “no,” write the amendment here, then re-date the posture document. Narrowing amendments do not need reviewer sign-off; enlarging amendments do.

Posture re-date: /capstone/security-posture.md re-dated to .

Amendments to this architecture

Dated, signed edits

Made during the build (Lessons 10.3–10.4) when reality collides with the design. Narrowing amendments do not require reviewer sign-off; enlargement amendments do.

This template accompanies Lesson 10.2 of AI Architect Academy. The six sections, the shared-state contract, and the kill switch are concept. Specific components and tool choices are recipe.