The Adoption Roadmap
Status: Complete · A phased, reversible path to SAE maturity — for the solo operator and the existing team adopting the practices without collapsing to N=1.
Getting Started gives you a ~30-minute taste of the loop on a toy slice. This page is the opposite timescale: how a real operator — or a real team — moves from "curious" to "running production on SAE discipline" over weeks, not minutes. It is a roadmap, not a mandate.
The defining property of this roadmap is that every phase is a reversible local choice. You can stop at the end of any phase and be strictly better off than when you started. There is no point at which you have to "go all in" or lose the value of what came before. SAE is adopted the way it is built — in bounded contexts, one slice at a time, with an exit always available.
SAE's most-attacked claim is the N=1 Architect-Engineer collapse — and rightly so (P6 concedes the bus-factor risk openly). But that collapse is a consequence of the principles, not a prerequisite for using them. The principles — spec as source of truth (P2), adversarial independence (P3), blast-radius gating (P5) — are valuable at any headcount.
So this roadmap runs two parallel tracks:
- Track A — The Solo Operator. One accountable person, Zero-Ops stack, the full collapse. This is SAE in its purest form.
- Track B — The Existing Team. A team adopts the practices — spec discipline, fresh-context QA, blast-radius gates — while keeping multiple humans in the loop. No collapse to N=1. The spec becomes the team's shared source of truth instead of one person's succession plan.
Both tracks walk the same phases (P0→P4) and hit the same maturity levels. The moves differ; the principles are identical.
Reality check. Track B is not "SAE-lite." It is the honest answer to the bus-factor objection: the practices that make SAE rigorous are precisely the ones that de-risk a team — a current spec, an independent verifier, and a gate on the irreversible reduce key-person dependency whether you have one operator or ten. The thing Track B gives up is the O(N²)→O(1) coordination win, because handoffs still exist. That is a deliberate, reversible trade.
Scaling frameworks (SAFe, Scrum-at-scale, and their cousins) mandate ceremonies and roles: fixed-cadence rituals, assigned title-holders, planning theatre. SAE mandates none of that. There is no required standup, no sprint ceremony, no certified role you must hire. The only non-negotiables are the First Principles themselves — and even those are adopted incrementally below. "Guardian" and "Architect-Engineer" are functions a context performs (Digital Org Chart), not job titles you must staff. If a move on this roadmap reads like a ceremony, it is a default you can delete, not a rite you must perform.
Maturity level: L0 → L1 (Ad-hoc → Practicing). See The Maturity Model.
Goal. Run one real (not toy) vertical slice through the full SAE loop, on a low-blast-radius surface, to feel the rhythm with something that actually ships.
| Track A — Solo | Track B — Team | |
|---|---|---|
| Concrete moves | Pick a genuinely useful but reversible slice (internal tool, read-only report, a feature behind a flag). Stand up a Zero-Ops stack. Run spec → single-shot slice → fresh-context Guardian → ship, as in Getting Started. | Same slice selection, but one volunteer runs it inside the existing repo and toolchain. Don't migrate infra. The pilot is a practice, not a platform decision. Review happens as a normal PR — the novelty is that a fresh context wrote the tests. |
| Entry criteria | You've read Module 2 and First Principles. A slice exists whose failure is cheap to undo. | Same, plus: a teammate has agreed to own the pilot and the team has agreed not to block it on existing process. |
| Exit criteria | One slice shipped where the spec was written first and an independent context refuted it before merge. You can describe what drifted. | Pilot slice merged; the team has seen a spec-first diff and a fresh-context test suite, and can name one thing it caught. |
Reversible? Entirely. If it doesn't click, you've shipped one useful feature and lost nothing. Stop here and you've still proven the loop to yourself.
Maturity level: L1 → L2 (Practicing → Disciplined). Anchored on P2 — the spec is the source of truth.
Goal. Make the spec authoritative for all new work, and start measuring spec-drift rather than assuming it away.
| Track A — Solo | Track B — Team | |
|---|---|---|
| Concrete moves | Adopt the SDD Spec Template. Version specs/ in the same commit as src/. Score each unit of work for Context Entropy (prep difficulty 1–13) before starting. Fix bugs in the spec first, regenerate. |
Same template, but the spec becomes the shared contract reviewers read first. Spec changes go through normal review. The Context Entropy score replaces (or augments) story-point estimation — it travels with the ticket. |
| Entry criteria | P0 exit met. | P0 exit met; team agrees new slices land spec-first. Legacy code is left alone (isolate the new from the old — P4). |
| Exit criteria | New work is spec-first by default; you have a (even rough) measured spec-drift signal and treat divergence as a tracked defect. | Same, at the team level: spec lives in the repo, reviewers cite it, and drift is logged — not litigated in standup. |
Reversible? Yes. Specs are just well-structured Markdown in your repo. Abandon SAE tomorrow and you're left with better-documented intent than most teams ever have. That is a strict improvement.
Reality check. "Never edit code directly" is the ideal (P2). Under pressure you will hand-patch a one-liner. The discipline that defines L2 is folding it back into the spec the same day — a stale spec is worse than none. P1 is "complete" when that habit is automatic, not when you've never violated it.
Maturity level: L2 → L3 (Disciplined → Verified). Anchored on P3 — the writer never judges its own work.
Goal. Make verification structurally independent — a fresh-context Guardian that is briefed to refute, not approve, reviewing the diff and not its own output.
| Track A — Solo | Track B — Team | |
|---|---|---|
| Concrete moves | Every non-trivial slice gets a Guardian pass in a clean context, tasked adversarially (grey-box refutation — see Operator Techniques). Diverse lenses for high-stakes changes. Confirmation is not a pass; an unrefuted change is. | Pair the machine Guardian with the human reviewer: the fresh context generates hostile tests and an attack list; the human adjudicates. This is where Track B is stronger than solo — you have genuine human adversarial independence on top of the fresh-context one. |
| Entry criteria | P1 exit met (a spec exists to verify against). | P1 exit met; reviewers willing to read a Guardian's refutation report as part of review. |
| Exit criteria | No high-blast-radius change merges without an independent refutation attempt on the diff. | Same; the team's definition-of-done includes a fresh-context adversarial pass, and it has caught at least one real defect the author's context missed. |
Reversible? Yes. The Guardian is a prompt-and-process pattern, not a tool lock-in. Drop it and you keep the tests it already wrote.
Maturity level: L3 → L4 (Verified → Operating). Supports P5 — gate the irreversible by blast radius.
Goal. Collapse operational toil so the operator's scarce attention goes to clarity and verification, not infrastructure — while the irreversible stays gated.
| Track A — Solo | Track B — Team | |
|---|---|---|
| Concrete moves | Migrate to managed primitives from the Approved Zero-Ops Tooling List: push-to-deploy, managed Postgres, serverless compute. Classify every change by blast radius; auth/payments/deletion/schema-drops never auto-apply. | Do not rip out your platform. Adopt the blast-radius gate as policy on your existing CI/CD: reversible changes flow fast, irreversible ones stop at an explicit human gate with independent (P3) review. Zero-Ops here means removing ceremony, not changing clouds. |
| Entry criteria | P2 exit met. Reversible changes can ship without manual ops. | P2 exit met; team agrees a blast-radius classification on changes. No infra migration required. |
| Exit criteria | Reversible changes deploy on push; every high-blast-radius operation has an explicit gate and an independent review. | Same gating policy live in the existing pipeline; team can point to the gate stopping (or deliberately passing) an irreversible change. |
Reversible? Yes — and this is the phase teams fear most, so it's worth stating plainly. Track B never has to leave its current stack. The portable, reversible part is the blast-radius discipline; the tooling choice is optional and independent.
Reality check. Zero-Ops is the most over-sold idea in this space. It does not mean "no operations" — it means no undifferentiated operations. You still own incidents, you still own the gate (P6). The win is that you stopped hand-rolling the parts a managed primitive does better, not that ops vanished.
Maturity level: L4 → L5 (Operating → Self-Improving). The full system: P1 feeding back on itself.
Goal. Close the loop so that production signals (incidents, drift, escaped defects) flow back into the spec and the verification regime automatically — the system gets clearer over time, not muddier.
| Track A — Solo | Track B — Team | |
|---|---|---|
| Concrete moves | Wire observability and error signals back to the spec: an escaped defect becomes a spec edit + a Guardian lens, not a hand-patch. Track measured spec-drift and Context-Entropy-vs-actual as standing KPIs. High-entropy areas get more spec automatically. | Same loop, team-owned: a blameless retro on an escaped defect produces a spec change and a permanent Guardian check. Metrics are dashboarded, not anecdotal. The team's spec — not any individual — accumulates the institutional memory. |
| Entry criteria | P3 exit met. Production signals are observable. | P3 exit met; team has somewhere to route production signals back into specs. |
| Exit criteria | Recurrent defect classes are extinct because the spec and Guardian lenses absorbed them. KPIs show drift trending down and escaped-defect rate falling. | Same, demonstrated at team scale; the system measurably improves release over release without adding ceremony. |
Reversible? Yes. The feedback wiring is additive — disconnect it and you fall back to P3, which is still better than where you started.
| Phase | Goal | Principle anchor | Maturity |
|---|---|---|---|
| P0 Pilot Slice | Feel the full loop on one real, reversible slice | All seven, lightly | L0→L1 |
| P1 Spec Discipline | Spec authoritative for new work; measure drift | P2 | L1→L2 |
| P2 Adversarial QA | Independent fresh-context refutation on the diff | P3 | L2→L3 |
| P3 Zero-Ops | Remove toil; gate the irreversible by blast radius | P5 | L3→L4 |
| P4 Self-Healing Loop | Production signals flow back into the spec | P1 | L4→L5 |
You do not have to reach P4 to win. Each phase pays for itself and stands alone. The roadmap is a sequence of independently-valuable, individually-reversible local choices — which is exactly what P4 — isolate bounded contexts looks like applied to adoption itself.
Reality check. This roadmap is a recommended ordering, not a measured pipeline. We sequence P1 before P2 because verifying against a clear spec is more useful than verifying against a vague one — but a team with strong existing QA might sensibly do P2's adversarial discipline early. Treat the order as a default with a stated rationale (P7), not a gate you must not reorder. Adapt the sequence to your binding constraint; do not skip the principles.
See also: The Maturity Model · Getting Started · First Principles · Module 4 — The Lean SAE Tech Stack · Approved Zero-Ops Tooling List · KPIs and Metrics · Objections · When Not to Use SAE