Assessment · Capstone rubric
The twelve-dimension capstone rubric
Twelve dimensions, four behaviorally anchored levels, and for every level the next specific thing to practice. It is written to be used twice on the same packet: once by you, once by someone who did not build it.
A rubric is not a grade. It is a way of turning “this feels underdone” into a sentence with a quotation attached, so the feedback names a force rather than a taste. Use it on the worked capstone first — scoring a packet you did not write is the cheapest way to calibrate.
How to score
- Cite evidence before you score. Every score names a quotation from the packet: a line of the frame, a signature, a table row, a paragraph of an ADR. If you cannot quote it, the dimension is not evidenced — which is a Developing score with a specific remedy, not a guess at what the author probably meant.
- Allow more than one valid design. These dimensions ask whether the reasoning holds, not whether the answer matches a key. A modular monolith and three services can both be Architect-ready on alternatives and trade-offs; what separates them is whether the drivers, the costs, and the revisit trigger are on the page.
- Never score style. Naming conventions, diagram tooling, document length, British or American spelling, and framework preference are outside every dimension. If your objection would survive a global find-and-replace, it is style. Say it as a note, not as a score.
- Score the dimension, not the packet. A strong architecture with no closeout plan is Architect-ready on one dimension and Developing on another. Averaging is for the summary line; the useful signal is the shape of the twelve.
- Prefer the lower level when torn. The levels describe what the work shows, not what its author could probably do. A Lead-ready claim that needs the author in the room to defend it is a Practicing artifact.
The four levels, in one line each. Developing: identifies symptoms, proposes a preference. Practicing: names forces, proposes a workable design, misses some consequences. Lead-ready: compares credible options, accepts costs explicitly, connects the decision to evidence and operation. Architect-ready: reasons across technical, organizational, economic and evolutionary consequences while keeping the decision understandable and revisable.
How peer reviewers use it
One reviewer who did not build the packet is worth more than three self-scores. The protocol below is deliberately short; it is a reading order, not a ceremony.
Peer-review guide
- Read alone first, for 20 minutes, taking no notes but quotations. Collect the lines you would need to justify any score. Do not score while reading.
- Score the twelve dimensions alone. Attach at least one quotation per dimension. Where you have none, write “no evidence found” — that is a finding.
- Ask the author to score themselves before you meet. The disagreements are the session; the agreements need no discussion.
- Meet for 45 minutes on the three largest gaps only. Start with the dimension where your scores differ most, and ask the author what evidence they were relying on. Frequently it exists and never made it onto the page — which is a communication finding, not a design one.
- End with one next practice per weak dimension, taken from the table. Not a list of twelve. Two or three, with dates.
Giving feedback about forces, not preferences
The difference between useful and useless design feedback is whether it can be argued with. A preference cannot: there is nothing to answer. A force can, because it names a cost that either exists or does not.
Preference — not useful
“I would have used a queue here.”
“This aggregate is too big.”
“The ADR should be more detailed.”
“I don’t like the module names.”
Force and consequence — useful
“This call inherits the vendor’s 99.5% availability into a path your own driver says must reach 99.95%. Which of the two numbers moves?”
“Three rules are inside this aggregate; only one needs a single transaction. The other two make every write contend. Is that contention priced anywhere?”
“The ADR does not say what would reopen it, so in six months the only way to revisit it is to relitigate it. What measurement would change your mind?”
“Note, not a score: the module names differ from the frame’s vocabulary. Style, unless it is causing translation errors — is it?”
Three rules make this repeatable. Name the force, then ask a question — the question is what makes it a review rather than a verdict. Say what the author’s own drivers imply, rather than what you would have chosen; their ranked drivers are the shared ground. Separate notes from scores out loud, so the author knows which remarks are binding and which are taste.
Agent-teacher prompts
An agent is a fast, tireless reviewer with one dangerous habit: asked for a critique, it will supply the missing evidence itself and then critique its own invention. Each prompt below closes that door explicitly. Copy one, paste your packet after it, and read the output as a list of places to look — never as findings you can quote onward.
# Prompt 1 — critique without invention
# You are reviewing my capstone packet against a twelve-dimension rubric.
# Rule: quote the exact line you are judging, before you judge it.
# If the packet contains no evidence for a dimension, write
# "no evidence in the packet" and move on. Do not infer it, do not
# assume a reasonable default, and do not supply a number I did not write.
# For each dimension give: the quotation, a level
# (Developing / Practicing / Lead-ready / Architect-ready), and one
# next practice. Nothing else.
# Prompt 2 — steelman the option I rejected
# Take the option I rejected in the ADR below and argue for it as strongly
# as the evidence in my packet allows. Use only forces I have written down.
# Where the argument needs a fact I have not supplied, list it under
# "missing evidence" instead of inventing a figure.
# Finish with one sentence: what would have to be true for the rejected
# option to win? That sentence is a candidate revisit trigger.
# Prompt 3 — find what I asserted without evidence
# List every claim in this packet that is stated as fact but carries no
# source, no measurement and no named owner. Quote each one.
# For each, write the cheapest test that could confirm or refute it
# within two weeks, and say what the test would cost me.
# Do not propose an architecture. Do not rank the claims by your own
# preference. Do not estimate any number that is not already in the text.
# Prompt 4 — walk the consequences, not the preferences
# For the design I chose, describe its consequence in four registers:
# code - what becomes harder to change, and where
# operations - what wakes someone up, and what they would do
# organization - which team now waits on which, and for how long
# economics - what recurs monthly, and what it scales with
# Where my packet gives no basis for a register, write "not stated".
# Never tell me what you would have preferred; tell me what my choice costs.
Treat agent output the way lesson 0010 treats generated code: a hypothesis with a plausible shape. The prompts above are safe because every one of them has an escape hatch that is cheaper for the model than fabricating — “no evidence in the packet”, “missing evidence”, “not stated”. If an answer never uses those phrases on a packet you know to be incomplete, the answer is not a review.
The twelve dimensions
Each dimension is one question about the work. Scoring is per dimension; the summary is the shape of the twelve, not their average. The scoring sheet with radio buttons lives on the capstone assessment.
1 · Problem and outcome clarity
Does the packet say whose behavior changes, from what to what, by when — and what must not get worse while it does?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Restates the brief as features. The word “portal” appears where a measured change should. No baseline, so no way to tell later whether it worked. | Rewrite the frame with lesson 0039’s seven rows, then circle every number without a source. |
| Practicing | States an outcome with a target number, but the baseline, the cohort or the deadline is missing, so the target cannot be checked. Guardrails are named as adjectives (“secure”, “accessible”) rather than measures. | Fix the baseline first: find the current measurement, or write down that you cannot and say what you will measure in week one. |
| Lead-ready | Baseline, target, cohort and date are all present and sourced. Non-goals are written down. Guardrails carry numbers and an owner, and the packet names which evidence would reopen the outcome itself. | Run the frame past someone outside the initiative and ask them the seven questions from lesson 0039’s quality test. |
| Architect-ready | Also prices the outcome: what the initiative is worth per month of earlier delivery, what the guardrail is worth if it degrades, and which cheaper intervention was considered and rejected before building anything. | Add the cost-of-delay line from the architecture-economics supplement and defend the intervention choice. |
| Evidence | Observable evidence to cite: Quote the outcome sentence, the baseline figure and its source, the guardrail list, and the non-goals section. | |
2 · Domain fidelity and invariant protection
Do the model’s names come from the business, and are its rules enforced by the objects that own the state rather than remembered by callers?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Model is a set of data holders with public attributes and a service layer of verbs. Rules live in if statements at call sites. Names are technical (ReturnData, process()). | Do lesson 0011’s move on one rule: make the state private and let the object refuse. |
| Practicing | Names come from the domain and one or two rules are enforced inside objects, but at least one invariant still depends on every caller remembering a check, and the aggregate boundary is not stated. | List every rule in your packet and name its enforcing object; the ones with no object are your gap. |
| Lead-ready | Every rule in the packet is attached to the object that owns the state it guards. Consistency boundaries are named, and the packet says which rules are strong-consistent and which are allowed to converge later. | Take the largest aggregate and argue for splitting it: which rule actually needs one transaction? See lesson 0055. |
| Architect-ready | Also shows where the model was deliberately kept shallow — which parts of the business were modeled as data because no rule guards them — and what evidence would justify deepening them. | Write the “why not an aggregate” note for two entities you modeled as plain data. |
| Evidence | Observable evidence to cite: Quote a class or protocol that refuses an illegal call, and name the invariant it protects. | |
3 · Coupling, cohesion, and dependency direction
Does each unit have one reason to change, and do dependencies point from volatile code toward stable code rather than the reverse?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Diagrams show boxes with arrows in both directions. Modules are named after layers or technologies. Global or module-level mutable state carries values between components with no declared dependency. | Take one function from your packet and write its reasons-to-change list, as in lesson 0001. |
| Practicing | Cohesion is reasonable inside modules, but at least one dependency points the wrong way — the domain imports an adapter, or a shared “common” module has become a junction that everything touches. | Grep the packet’s code for module-level mutable containers and move one to a composition root (lesson 0019). |
| Lead-ready | Dependency direction is stated as a rule, not a hope: the packet names which modules may import which, and shows the composition root where wiring happens. Every cycle is either absent or explicitly accepted with its cost. | Write the allowed-import table from lesson 0022 and check the code against it by hand. |
| Architect-ready | Also treats the dependency rule as enforceable — a fitness function or import check — and explains which coupling was kept on purpose because removing it would cost more coordination than it saves. | Turn that table into a failing test, then make it pass. Lab checkpoint: fitness functions. |
| Evidence | Observable evidence to cite: Quote the allowed-import table or dependency rule, and one place in the code where it is enforced. | |
4 · Quality and depth of module boundaries
Is each boundary narrow at the interface and substantial behind it, or has it merely moved code without hiding anything?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Boundaries follow file-type or layer conventions. Interfaces expose their implementation: a repository that takes SQL, a port named after a vendor, a “service” that forwards one call to one other call. | Re-read lesson 0009 and rewrite one interface so no vendor word appears in it. |
| Practicing | Boundaries follow responsibilities and hide some detail, but at least one leaks — a vendor type in a signature, a database cursor returned to the domain, or a port with a method only one adapter can satisfy. | Find the leak: run the vendor-word search across the packet’s signatures. Lesson 0023. |
| Lead-ready | Each boundary is justified by what changes on either side of it. Interfaces are expressed in the domain’s language, and the packet names what each module hides and what it deliberately exposes. | For each boundary, write the sentence “this hides …”; the ones you cannot finish are shallow (lesson 0056). |
| Architect-ready | Also states the replaceability test for each boundary: what a second implementation would have to do, and whether one has ever been written or is realistically foreseeable. | Write the second implementation for your riskiest port, even as a fake, and see what the interface forced you to change. |
| Evidence | Observable evidence to cite: Quote one interface definition and the module it hides; note whether any vendor or storage type appears in it. | |
5 · Use of measurable architecture drivers
Are the qualities that shaped the design written as scenarios with a stimulus, a response and a measure — and prioritized against one another?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Quality requirements appear as adjectives in a list: fast, scalable, secure, maintainable. Nothing in the design can be traced back to any of them, and no two are ranked. | Rewrite one adjective as a scenario using lesson 0043’s six parts. |
| Practicing | Some scenarios have numbers, but they lack a stimulus or an environment, so it is unclear when the number applies. All drivers are listed as equally important. | Add the environment clause: under what load, in what failure state, does the number hold? |
| Lead-ready | Drivers are written as scenarios with source, stimulus, environment, response and measure. They are ranked, and the packet shows at least one design choice that a lower-ranked driver lost. | Rank your drivers and find the design decision that the third-ranked one lost. Say so in the packet. |
| Architect-ready | Also states which drivers are being monitored in production and what the system does when one is missed — the driver has a fitness function or an alert, not just a paragraph. | Attach a fitness function to your top driver. Lab checkpoint: fitness functions. |
| Evidence | Observable evidence to cite: Quote one full scenario, its rank, and the design decision it decided. | |
6 · Quality of alternatives and trade-off reasoning
Were at least two genuinely different designs compared against named forces, with the losing option’s strengths and the winner’s costs both stated?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | One option is presented and defended. Alternatives, if listed, are variants of the same mechanism or straw men. The justification is a preference (“cleaner”, “more modern”) rather than a force. | Design it twice: write a second option that uses a different mechanism, not a different vendor (lesson 0046). |
| Practicing | Two real options are compared, but on unequal terms: the chosen one is described in detail and the other in a sentence. Costs of the winner are acknowledged generally, not specifically. | Give the rejected option the same word count as the chosen one, then re-read both. |
| Lead-ready | Options differ in mechanism, not supplier. Each is scored against the ranked drivers. The accepted cost of the winner is stated in concrete terms, and the packet names what would have to be true for the loser to win. | Add the revisit trigger and the dissent line to your ADR. Practice on the decision-change simulations. |
| Architect-ready | Also reasons across registers: what the choice costs in code, in operations, in coordination between teams, and in recurring money — and sets a measurable trigger that reopens the decision. | Price the recurring cost of the winner over three years, as in lesson 0027’s ledger. |
| Evidence | Observable evidence to cite: Quote the option table, the accepted-cost sentence, and the revisit trigger. | |
7 · Data ownership, contract evolution, and failure semantics
Does exactly one component own each piece of state, and is every contract’s failure and evolution behavior written down before it ships?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Ownership is implicit — whichever component writes last. Status is a string column set from several places. Failure behavior is “it throws”; compatibility is “we will version it if we need to”. | Draw one entity’s transition table with the five columns from lesson 0054. |
| Practicing | Ownership is stated for the main entities, and there is a state diagram, but transitions have no actors or rules, and the contract says what a call returns without saying what a timeout, a retry or a duplicate means. | Add actors and rules to the transitions, then ask who else can write this state today. |
| Lead-ready | Every state machine has from, command, to, actor and rule. Writes that can be retried carry an idempotency key. The compatibility policy says what may be added freely and what counts as breaking. | Write the compatibility policy for your riskiest contract and test it against three changes (lesson 0057). |
| Architect-ready | Also plans the migration: expand and contract steps, each independently deployable and reversible, with the evidence that makes contraction safe and the consumers that were verified against it. | Write the expand/contract plan for one column rename and name the reversal point of each step. |
| Evidence | Observable evidence to cite: Quote the transition table, the idempotency mechanism, and the compatibility policy. | |
8 · Testability, observability, security, and reversibility
Can the design be tested where the risk is, watched in production, defended at its trust boundaries, and undone if it is wrong?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Testing is “we will add tests”. Observability is “we have logs”. Security appears once, as authentication. Rollback is a redeploy of the previous build, including the schema. | Write one characterization test around behavior you are afraid to change. Lab: phase 1 checkpoint. |
| Practicing | Tests exist and match some of the risk. There are metrics, but they measure the system rather than the outcome. Authorization is mentioned but not at the object level. Reversal is planned for code, not for data. | Add one outcome metric next to your system metrics — the number the initiative frame promised. |
| Lead-ready | Tests are chosen by risk, with characterization tests protecting what is not yet understood. Outcome telemetry sits beside system health. Trust boundaries and object-level authorization are named. Every step is reversible or has a written compensation. | Write the abuse cases for your riskiest endpoint, then the negative acceptance examples that prove them. |
| Architect-ready | Also rehearses the reversal, names who may pull it and on what signal, and treats accessibility and data retention as acceptance criteria rather than a later audit. | Rehearse the rollback against real data volume and record how long it actually took. |
| Evidence | Observable evidence to cite: Quote the risk-to-test mapping, one outcome metric, and the rollback or compensation step. | |
9 · Delivery sequencing and uncertainty reduction
Does the plan buy down the largest uncertainty first, in slices that are thin, vertical, and releasable?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | The plan is a component list in build order: database, then services, then user interface. Nothing is demonstrable until most of it exists. Risk is scheduled last because it is hard. | Re-cut your first slice so it crosses every layer for one user, as in lesson 0042. |
| Practicing | Slices are vertical, but they are sequenced by feature value alone. The riskiest unknown sits in the middle of the plan, and no milestone is defined by evidence rather than by output. | Reorder the plan by uncertainty: which slice would tell you soonest that the design is wrong? |
| Lead-ready | A walking skeleton proves the risky path end to end early. Slices are ordered so each one retires a named assumption, and every milestone states what will be known that was not known before. | Define each milestone by the evidence it produces (lesson 0047). Lab: phase 4 checkpoint. |
| Architect-ready | Also names the dependencies owned by other teams, the fallback if each arrives late, and the one variable in the forecast that is allowed to move when evidence changes. | Write the dependency map with a fallback for each external commitment, and the date each fallback must be triggered. |
| Evidence | Observable evidence to cite: Quote the slice list, the walking-skeleton definition, and the assumption each early slice retires. | |
10 · Product, design, and engineering collaboration
Is the work visibly shaped by more than one discipline, with decision rights named and dissent recorded rather than smoothed away?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Artifacts are engineering documents. Product appears as a requester and design as a consumer of screens. “We agreed” appears with no decider named. | Fill in the decision-rights table from lesson 0039 and get one other discipline to disagree with it. |
| Practicing | Product and design contributed to discovery, but decision rights are informal and disagreement is absent from the record. Research evidence appears in the frame but does not change any artifact. | Run one divergence exercise where people write independently before anyone speaks (lesson 0040). |
| Lead-ready | Decision rights are written per decision type. Discovery diverged independently before converging on evidence. At least one artifact visibly changed because of design or product evidence, and dissent is recorded with its disproving test. | Record one dissent in an ADR together with the evidence that would prove it right. |
| Architect-ready | Also shows the team operating: work in progress limited, swarming on the risky slice, and a cadence in which the same three disciplines review the same evidence weekly. | Charter the team explicitly: roles, work-in-progress limit, escalation trigger (lesson 0048). |
| Evidence | Observable evidence to cite: Quote the decision-rights table and one artifact that changed because of non-engineering evidence. | |
11 · Technical communication and decision clarity
Can an executive, a product manager, and a new engineer each get what they need from the same body of work without being told a different story?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | One artifact serves all audiences: a diagram with every box on it, or a document that explains the mechanism without ever stating the decision. Uncertainty is hidden or presented as confidence. | Split your one diagram into a context view and a container view (lesson 0044). |
| Practicing | There are separate summaries for different audiences, but the numbers or the framing differ between them. Diagrams mix abstraction levels, so containers and classes share one picture. | Write the same decision twice: five lines for an executive, one page for an engineer, and check the numbers match. |
| Lead-ready | Context, container and dynamic views are separate and consistent. Decisions are one page each: context, forces, options, decision, consequences. Uncertainty is stated as a range with the variable that moves it. | State one forecast as a range and name the variable that would move it (lesson 0047). |
| Architect-ready | Also communicates change well: when a decision is superseded, the earlier record survives, the new one cites the evidence, and both technical and non-technical audiences hear it before they hear the consequence. | Draft the supersede note for a decision that changed, and hand it to the portfolio narrative. |
| Evidence | Observable evidence to cite: Quote the executive summary, one ADR, and the container diagram; check the three agree. | |
12 · Operational ownership and initiative closeout
After release, is it clear who owns the running system, what evidence closes the initiative, and what temporary machinery gets removed?
| Level | What the work shows | Next specific practice |
|---|---|---|
| Developing | Release is the end of the plan. Ownership after launch is unstated. Feature flags, migration scaffolding and dual writes have no removal date. Success is declared from the launch, not from the outcome measure. | Name the on-call owner and the first alert threshold before you plan the launch. |
| Practicing | There is an on-call owner and a dashboard, but the closeout has no criteria: the initiative ends when the work runs out. Temporary machinery is listed but not scheduled for removal. | Write the closeout criteria as the outcome number plus each guardrail (lesson 0050). |
| Lead-ready | Ownership, runbooks and alert thresholds are handed over explicitly. Closeout is defined by the outcome measure and the guardrails, and the packet names each piece of temporary machinery and the condition that removes it. | List every flag, dual write and shim, and give each a removal condition (lesson 0035). |
| Architect-ready | Also transfers learning, not just systems: what the initiative disproved, which assumptions changed, and what the next team should not repeat — recorded where a stranger will find it. | Write the learning transfer: what you believed at the start that turned out to be false. |
| Evidence | Observable evidence to cite: Quote the ownership handover, the closeout criteria, and the removal condition for one flag or shim. | |
Reading the shape, not the average
Twelve scores make a profile. Three profiles come up often enough to name:
| Profile | What it looks like | What it usually means |
|---|---|---|
| Strong code, thin initiative | Dimensions 2–4 at Lead-ready, 1, 9, 10 and 12 at Developing. | The design is sound and nobody outside engineering could act on it. Practice in Phase IV: start with lesson 0039. |
| Strong plan, soft structure | Dimensions 1, 9, 10, 11 at Lead-ready, 2–4 and 7 at Developing. | The initiative would be led well and the system would rot. Practice in Phases I and V: 0011 and 0054. |
| Everything Practicing | Ten or more dimensions at Practicing, none at Developing, none at Lead-ready. | Usually one missing habit rather than twelve: consequences are named generally instead of specifically. Pick the two lowest-confidence dimensions and add the numbers. |
What this rubric is not. It is not a certificate, and a score on it is not a qualification. Its evidence is one self-assessment plus one peer review of one packet you had unlimited time to write. That is enough to tell you where to practice next, and it is not enough for anyone else to hire on. The thing that transfers is the packet itself — see the portfolio guide.
Reference: the initiative playbook holds the blank templates for every artifact this rubric scores; the glossary holds the vocabulary it uses.