Decide → Record → Enforce → Review
The loop that keeps an architecture and a system agreeing with each other. Four steps, tool-agnostic, and cheap enough that a team of three can run it. The Spine is where its output lands.
Runs on any documentation format · No board, no approval queue, no tooling requirement
The loop
Each step produces one concrete thing. If a step produces nothing you can point at, it did not happen.
- Step 01
Decide
Name the decision, the options you rejected, and the quality goal it serves. If you cannot name the goal, you are choosing a technology, not making an architectural decision.
A decision with an owner and a date.
The choice still gets made — by whoever writes the code first, without the context to make it well.
- Step 02
Record
Write it once, in the repo, as an ADR. Add the entry to spine.yaml so it is addressable by id from a guardrail, a diagram or an agent prompt.
arch/decisions/ADR-NNNN.md plus one line in spine.yaml.
Six months on, the rationale exists only in the head of whoever has since changed teams.
- Step 03
Enforce
Bind each quality goal to a check that can fail: a build-time rule, a test, a runtime SLO, or an eval threshold for anything LLM-shaped. Unenforced intent decays silently.
A guardrail id in CI that fails the build when the goal is violated.
The architecture drifts and nobody finds out until the incident review.
- Step 04
Review
On a cadence, not on a crisis: expire constraints that stopped being true, supersede decisions rather than editing them, and re-price the risks. Stamp the review date.
An updated review block, and superseded decisions that still read as history.
The spec becomes confidently wrong — worse than absent, because people trust it.
How each step gets performed instead of done
Nobody announces they are skipping a step. They do a version of it that produces no output, which costs the same and is much harder to notice.
| Step | What it looks like | The tell |
|---|---|---|
| Decide | A meeting concludes with alignment and no decision, or a decision with no goal attached. | Nobody can say which quality goal the choice buys. |
| Record | A wiki page per topic, rewritten in place each time the design changes. | There is no way to read what the previous decision was, or why it stopped being right. |
| Enforce | A quality attributes table where every row is an adjective and no row has an owner. | No build has ever failed because of anything in that table. |
| Review | A review triggered by an incident, then not again until the next one. | Constraints in the file are older than the reasons they were written for. |
Cadence
The loop is not run end to end on a schedule. The steps have different clocks, and conflating them is why architecture governance turns into a quarterly document exercise.
Every change
Decide and Record. Only for changes that cross a boundary or cost more than a sprint to reverse.
Every pipeline run
Enforce. Guardrails run unattended or they do not run.
Quarterly
Review. Expire constraints, re-price risks, stamp the date, supersede what is no longer true.
Never
A full rewrite of the spec. If that feels necessary, the review step has not been happening.
When not to run this
- During an incident. Recording decisions mid-incident produces bad decisions and worse records. Fix it, then run Decide and Record on the change you actually kept.
- On a codebase you are about to delete. A strangler-fig migration needs the loop on the new system, not the old one. The old one needs a risk register and an end date.
- Before you can enforce anything. If there is no CI, start there. Decide and Record without Enforce degrades into documentation, and documentation is the thing this loop exists to improve on.
What each step needs from you
ADR Generator
Nygard, MADR 4.0 or Y-statement, filled in and copied out as Markdown.
Fitness functions catalog
Sixty checks by quality attribute, including LLM eval thresholds.
SLO & error budget calculator
Turn an availability goal into a burn rate you can alert on.
Failure catalog
Fourteen failure modes to re-price your risk register against.
Frequently asked
How is this different from an architecture review board?
A board is a gate: work stops until a group approves it. This is a loop that runs inside the work — the decision is recorded by whoever makes it, and the enforcement is automated rather than social. Boards fail in the same way in every organisation: they become a queue, and the queue becomes something to route around. A guardrail in CI cannot be routed around by scheduling.
Who owns each step?
Whoever makes the decision records it — not an architect who was told about it later. Guardrails are owned by the team whose build they fail, because a check somebody else owns gets disabled the first time it is inconvenient. The review is owned by one named person with a calendar entry; a review owned by a team is owned by nobody.
How often should an architecture be reviewed?
Quarterly for a system under active development, half-yearly for one in steady state. The trigger is the calendar, not an incident: reviewing after an incident only ever finds the thing that already broke. What a scheduled review catches is the constraint that expired, the decision that has been quietly superseded in code but not on paper, and the risk that changed price.
What if the team will not maintain it?
Then reduce the surface until they will. Two quality goals with two real guardrails, and decisions recorded only for changes that cross a service boundary. Adoption failures here are almost never about discipline — they are about a template that asked for twelve files on day one and got nothing on day thirty.
Does this work when agents write most of the code?
It works better, because the loop produces exactly what an agent lacks: an addressable decision, an unambiguous boundary, and a check that catches a violation before review does. The one thing that changes is volume — with agents generating changes faster than humans can review them, the Enforce step stops being good practice and becomes the only thing standing between intent and drift.
The method needs somewhere to write
The loop produces artefacts. Here is where they go.
The Spine is the directory this method fills: decisions, quality goals bound to guardrails, and a review stamp that tells you how old the whole thing is.