Assessment · Capstone
The capstone assessment
One initiative, fourteen artifacts, twelve rubric dimensions, and one person who did not write it. This is the only assessment in the course whose evidence is a thing you could show somebody outside it.
Read this page before you start writing, and then do not read the worked capstone until your own packet is finished and self-scored. The worked version is a strong answer to the same problem; reading it first replaces your judgment with its judgment, and the whole point of the exercise is to find out what yours produces.
What to submit
The initiative is yours to choose. Three options, in descending order of how much the result is worth to you afterwards:
- A real initiative you are leading or have led. Best evidence, and the one that needs the anonymization guide before it leaves your laptop.
- The returns-resolution initiative from lessons 0039–0060, written your own way. You will be able to compare artifact by artifact against the worked version, which makes the feedback sharper and the exercise less like your day job.
- The order-amendment initiative from the Phase 4 assessment, extended. Three of its artifacts already exist if you did that assessment.
Blank templates for every artifact below are in the artifact pack, in printable HTML and in Markdown suitable for a repository. The initiative playbook has the same templates with the guidance attached.
| # | Artifact | Length that is usually right | Taught in |
|---|---|---|---|
| 1 | Initiative frame | one page | 0039 |
| 2 | Assumption map, with the test chosen for each | one page | 0040 |
| 3 | Current-state and target workflow | two diagrams plus notes | 0041 |
| 4 | Story map with release slices | one map | 0042 |
| 5 | Acceptance examples for two rules and two failures | four examples | 0042 |
| 6 | Prioritized architecture drivers | five to eight scenarios, ranked | 0043 |
| 7 | C4 context, container, and one dynamic view | three diagrams | 0044 |
| 8 | State machines and contract review | one table per entity, one contract | 0054, 0057 |
| 9 | Option comparison and one completed ADR | one table, one page | 0046 |
| 10 | Walking skeleton and delivery/dependency map | one page | 0047 |
| 11 | Team charter and decision-rights table | one page | 0048 |
| 12 | Test, telemetry, and staged-rollout plan | one page | 0049 |
| 13 | One simulated weekly review, including a changed decision | half a page | 0050 |
| 14 | Closeout: ownership handover and what gets removed | half a page | 0060 |
Three properties matter more than any artifact. Every artifact traces to an outcome, an assumption, a driver, a risk, or a rollout decision — if one traces to nothing, delete it rather than defend it. Rejected options and accepted costs are visible. And the packet contains at least one decision that changed, with both records intact. A packet in which nothing was ever wrong is a packet describing an initiative that never met any evidence.
Structured self-review, before you read anything
Do this with your own packet open and nothing else. It takes about ninety minutes and it is the step most often skipped, because reading the worked version feels more productive. It is not: the errors you find yourself are the ones you stop making.
Pass 1 — traceability, 20 minutes
- Take each artifact in turn and write, in the margin, the outcome, assumption, driver, risk or rollout decision it exists to serve. Any artifact with an empty margin is either untraceable or undocumented — decide which, out loud.
- Now go the other way: for each of your outcomes and top three drivers, name the artifact that would change if it moved. A driver nothing depends on decided nothing.
- Find every number in the packet. Circle the ones with no source. Count them.
- Find every “must” and every “we will”. Circle the ones with no named owner.
Pass 2 — the artifacts most likely to be thin, 40 minutes
- Frame. Hand it to somebody outside the initiative. Can they say why now, for whom, what measurable change, what is excluded, what cannot move, what might be false, and who decides? If they can only list features, it is still a brief.
- Drivers. Is every one a scenario with a stimulus, an environment and a measure? Which design decision did your third-ranked driver lose?
- Options and ADR. Do your options differ in mechanism, or only in supplier? Does the record say what would reopen it, and does anything measure that?
- State and contracts. Does every transition have an actor? Does your compatibility policy define breaking, rather than referring to a version number? Which of your transitions has no reversal at all — and did you say so?
- Delivery map. Which slice retires the largest unknown, and where is it in the order? What is the fallback for each external dependency, and on what date is it triggered rather than hoped past?
- Rollout and closeout. Is any step in your plan reversible only by restoring data? Which temporary machinery has no removal condition?
- The changed decision. Is the superseded record still readable, and does the new one cite the evidence rather than the conclusion?
Pass 3 — three audiences, 20 minutes
- Write the five-line executive version from your packet, without adding anything not already in it. If you have to invent a number, that number was missing.
- Write the one-paragraph version a new engineer needs on their first day. Check the two agree.
- Read your riskiest decision aloud as if the person carrying its consequence — the on-call engineer, the support agent, the warehouse — were listening. Does it mention them?
Only now open the strong packet and the weak one, artifact by artifact, with the reviewer notes beside them. Read the weak packet carefully: it is the more useful of the two, because its failures are the plausible ones.
The scoring sheet
Twelve dimensions, four levels. The summary line below updates as you score. It gives you an average because people want one; the number you should actually act on is the shape — see reading the shape, not the average.
Score each dimension against the rubric, citing a quotation from your own packet before you choose a level. Where you have no quotation, score Developing — “I know I could do it” is not evidence in a packet.
1 · Problem and outcome clarity
2 · Domain fidelity and invariant protection
3 · Coupling, cohesion, and dependency direction
4 · Quality and depth of module boundaries
5 · Use of measurable architecture drivers
6 · Quality of alternatives and trade-off reasoning
7 · Data ownership, contract evolution, and failure semantics
8 · Testability, observability, security, and reversibility
9 · Delivery sequencing and uncertainty reduction
10 · Product, design, and engineering collaboration
11 · Technical communication and decision clarity
12 · Operational ownership and initiative closeout
Not scored yet.
Scores are kept in this browser only, alongside your lesson progress. They are for you; nothing is submitted anywhere.
Thresholds, and what they are worth
Two thresholds, both requiring a peer review. Neither is a qualification.
Lead-ready
- No dimension below Practicing.
- At least eight of twelve at Lead-ready or above.
- Including all four of: problem and outcome clarity, alternatives and trade-offs, delivery sequencing, and communication and decision clarity. Those four are what a lead is asked for on the first day.
- A peer reviewer, scoring independently, lands within one level on at least nine of twelve.
Architect-ready
- No dimension below Lead-ready.
- At least six of twelve at Architect-ready.
- Including all three of: alternatives and trade-offs, data ownership, contracts and failure semantics, and operational ownership and closeout. Those three are where consequences outlive the person who chose them.
- A peer reviewer lands within one level on at least ten of twelve, and the packet contains a decision that changed on evidence, with both records intact.
What this is evidence of, honestly. One packet, written under no deadline, about an initiative whose outcome you did not have to live with, scored by you and one other person who is probably also learning. That is real evidence of reasoning and no evidence at all of delivery. It is not a certificate, it does not transfer, and nobody should hire on it.
What it is genuinely good for: knowing where to practice next; having something concrete to talk about in an architecture interview (see the interview narrative); and giving you a vocabulary for the review conversations you will be running rather than sitting in. The thing that makes it credible to somebody else is the packet, not the score — so keep the packet.
The strongest available upgrade is not a higher score. It is running one artifact from this packet — a driver scenario, an ADR with a revisit trigger, a rollout gate — on a real initiative at work, and writing down what happened when reality disagreed with it.
The peer-review protocol
The full guide, including how to give feedback about forces rather than preferences, is in the rubric. This is the session itself.
| When | Who | What happens |
|---|---|---|
| Before, −3 days | author | Send the packet and nothing else. No walkthrough, no context call, no “the thing to know is…”. If the packet needs you to be understood, that is the first finding. |
| Before, −1 day | reviewer | Read alone for 20 minutes collecting quotations only. Then score the twelve dimensions alone, attaching a quotation to each. Send the scores to the author before the session. |
| Before, −1 day | author | Compare with your own scores. Rank the three largest disagreements. Do not prepare defences; prepare the evidence you were relying on. |
| 0–10 min | both | The author states the outcome, the top driver, and the decision they are least sure about. Three sentences. The reviewer says nothing. |
| 10–40 min | both | The three largest disagreements, one at a time. For each: the reviewer reads their quotation, the author says what evidence they had, and both decide whether the gap is design or communication. Those need different fixes. |
| 40–45 min | author | Write two or three next practices with dates, taken from the rubric’s next-practice cells. Not twelve. |
Two rules that make the session work
The reviewer never proposes a design. The moment a review becomes a competing proposal, the author defends rather than examines, and the session produces one more opinion instead of one finding. Name the force, ask the question, stop.
Disagreement that survives the session is recorded, not resolved. Write it into the packet as dissent, with the evidence that would settle it. Two people who both understand a trade-off and choose differently is the normal, healthy end state; pretending otherwise is how design reviews become theatre.
After the capstone
Take the exit diagnostic — twelve harder versions of the six judgments you were routed on at the start, with a side-by-side comparison. Then use the portfolio guide to turn the packet into something you can show at three different altitudes.