Assessment · How it works
Assessing design judgment
Four layers, one rubric, and no certificate. The question every page here tries to answer is not whether you have read the course, but whether your judgment holds up when the situation is unfamiliar and more than one answer is defensible.
Quiz completion is not evidence of lead readiness, and this course says so in its own improvement plan. So the scenario questions here are the cheap layer — they catch recognition failures fast. The evidence that matters is written: eighteen open-response tasks across five phases, and one capstone packet scored against twelve dimensions by you and by somebody who did not write it.
The four layers
| Layer | What it measures | What it cannot measure | When |
|---|---|---|---|
| Entry diagnostic | Whether you can already recognize the six judgments the course is built on, and where that recognition first becomes inconsistent. | Anything you can build. Twelve multiple-choice questions measure recognition, which is a much smaller act than noticing the same defect in code nobody flagged. | Before lesson 0001 |
| Phase assessments × 5 | Six scenarios plus three written tasks per phase: a reasons-to-change list, an import table with a test that enforces it, an option table with its arithmetic, a state machine with actors. | Whether you would do any of it under a deadline, with a stakeholder disagreeing. | At the end of each phase |
| Capstone assessment | Whether fourteen artifacts about one initiative hold together: every one tracing to an outcome, an assumption, a driver, a risk or a rollout decision. | Delivery. The packet describes an initiative whose consequences you did not have to live with. | After Phase V |
| Exit diagnostic | The same six judgments on harder situations, with a side-by-side comparison against where you started. | The difference between growth and having seen the instrument before. It says so on the page. | After the capstone |
Start here: the entry diagnostic
Twelve scenarios, two for each of the six skills the course teaches: find a structural problem, identify a leaking boundary, protect a domain invariant, compare an architectural trade-off, turn a vague requirement into a quality-attribute scenario, replan an initiative after evidence changes. It routes you to the earliest phase where your judgment stops being consistent, and it explains the routing rule and its limits rather than presenting a verdict.
It replaces the older way of choosing a starting point — asking people what they already know. Self-reported familiarity and applied judgment come apart most severely in exactly the population this course is for: experienced developers who have read a great deal about design.
The five phase assessments
Each one is six scenario questions and three written tasks, and takes about a hundred minutes including self-scoring. The written tasks are the point. Each ends with a structured self-review you run against your own text, a self-score against three or four rubric dimensions, and only then a strong and a weak sample answer with an explanation of what separates them.
| Assessment | After | The three written tasks |
|---|---|---|
| Phase 1 · Core Designer | lessons 0001–0014 | A reasons-to-change list and the first boundary to cut; an invariant list and a refusal in code; a structural review of generated code with a merge decision per finding. |
| Phase 2 · System Designer | lessons 0015–0026 | An ownership table and a composition root; an allowed-import table and a fitness function that fails today; three failures placed across three layers. |
| Phase 3 · Master Designer | lessons 0027–0038 | An option table with a break-even year and a revisit trigger; a per-operation consistency ledger; an irreversible change cut into reversible slices. |
| Phase 4 · Initiative Lead | lessons 0039–0050 | A brief turned into a frame; two options, a spike brief and an ADR; a walking skeleton and a slice list with evidence milestones. |
| Phase 5 · System Architect | lessons 0051–0060 | A state machine with actors and honest recovery; internal and external contracts with a compatibility policy; an architecture style with its rejected alternative and release path. |
Phase 4 deliberately uses a different initiative from the one in the lessons, so nothing there can be answered from memory. Phase 5’s three tasks are three of the capstone’s artifacts — keep what you write.
The capstone assessment
One initiative, fourteen artifacts, and the only evidence in the course you could show to somebody outside it. The capstone assessment covers what to submit, a ninety-minute structured self-review to run before you open the worked packet, the twelve-dimension scoring sheet, the lead-ready and architect-ready thresholds, and the peer-review protocol.
Blank templates for every artifact are in the artifact pack.
The exit diagnostic
Twelve scenarios matched one for one to the entry diagnostic: same six skills, different situations, and each one built so that the obvious answer is a real finding that is not the biggest one. It ends with a table you fill in yourself, comparing what you reasoned from at entry with what you reason from now — and asking, for each skill, what evidence exists that anything changed.
Take the exit diagnostic → (after the capstone)
The four levels
Every self-score on every page uses the same four, so a Practicing in Phase 1 means the same thing as a Practicing on the capstone.
| Level | What the work shows |
|---|---|
| Developing | Identifies symptoms and proposes a preference, without naming forces or evidence. Often correct, and unarguable — there is nothing in it for a reviewer to disagree with. |
| Practicing | Names the relevant forces and proposes a workable design, with some consequences missing or stated generally rather than specifically. |
| Lead-ready | Compares credible options, accepts costs explicitly, and connects the decision to evidence and to how the thing will be operated. |
| Architect-ready | Reasons across technical, organizational, economic and evolutionary consequences, while keeping the decision understandable and revisable. |
How scoring works, and its three rules
- Every score cites observable evidence. A quotation from the work, before the level is chosen. “I know what I meant” is not evidence, and neither is the author being in the room — a Lead-ready claim that needs defending in person is a Practicing artifact.
- More than one design is valid. A modular monolith and three services can both score Architect-ready; what separates them is whether the drivers, the accepted costs and the revisit trigger are on the page. The scenario questions have one best answer; nothing else here does.
- Style is never scored. Naming conventions, diagram tooling, document length, framework preference. If your objection would survive a global find-and-replace, it is style: say it as a note, not as a score.
And feedback always ends in a next specific practice rather than a grade. Every rubric row carries one; every self-score on these pages prints one when you finish scoring.
Where your answers live. Scenario answers and self-scores are kept in this browser alongside your lesson progress, so you can leave a page and come back. Nothing is submitted anywhere, and clearing site data clears it. The course index has progress export and import if you want a durable copy.
Everything on this shelf
- Entry diagnostic — twelve scenarios, routes you to a starting phase.
- Phase 1 · Phase 2 · Phase 3 · Phase 4 · Phase 5 — six scenarios and three written tasks each.
- Capstone assessment — what to submit, the self-review, the scoring sheet, the thresholds, the peer-review protocol.
- Exit diagnostic — the harder twin of the entry diagnostic, plus the entry-versus-exit comparison.
- The capstone rubric — twelve dimensions, four levels, the evidence to cite, the next practice per level, the peer-review guide and four agent-teacher prompts that ask for critique without inventing evidence.
Alongside them: the code lab for practicing Phases I–III on a running system, the decision-change simulations for the judgment no written test reaches, and the portfolio guide for turning the capstone into something you can show.