An architecture review board exists to stop expensive, hard-to-reverse mistakes reaching production. That is the whole mandate. Every clause below either serves it or should be cut.
The failure mode is well known to anyone who has sat on one. The board starts with good intentions, accumulates scope, and within two quarters it is a fortnightly meeting where six people look at slides for changes that shipped last week. Teams learn to schedule around it. The board's real output becomes an action log nobody reads.
What follows is a terms of reference you can adapt, followed by the operating rules that matter more than the document.
Terms of reference — template
1. Purpose
The board exists to prevent architecturally significant decisions from being made implicitly, and to stop changes with large blast radius reaching production without adversarial scrutiny.
It does not exist to approve work, to allocate resources, to review delivery progress, or to act as a design authority for changes inside a single team's boundary.
2. Scope — what comes to the board
Define this by blast radius, never by team, cost, or seniority of the requester. A change is in scope when it does one or more of:
- Changes a data model, storage engine, or persistence contract other systems depend on
- Introduces a new component to the production topology, or removes one
- Touches a safety, money, identity, or regulatory-reporting path
- Establishes a pattern other teams are expected to follow
- Deviates from a documented standard or architecture decision record
- Creates a new external integration or exposes a new public interface
Everything else is the team's decision. Say this explicitly in the document, because an ARB that does not publish what is out of scope will be handed everything.
3. Membership and seats
Each seat has a narrow mandate and a verdict. Narrow mandates are what make a board more than a group of opinions.
| Seat | Class | Single question |
|---|---|---|
| Chair | Decides | What is the defensible decision, and who owns each consequence? |
| Security | Blocking | What real, exploitable risk does this create in our context? |
| Compliance | Blocking | Does this silently deviate from the written canon? |
| Operability | Blocking | What happens to this at 3am, and who carries it? |
| Data | Advisory | What does this do to the shape and lineage of our data? |
| Standards | Advisory | Does this fragment the landscape or fit the target state? |
| Pragmatist | Advisory | What complexity here has not earned its keep? |
Blocking seats can stop a change until their finding is resolved or formally waived. Advisory seats inform the chair's judgment. Keep the distinction sharp: a board that treats "this could be more elegant" and "this loses money on restart" as equivalent will be ignored within a fortnight.
4. The chair's role
The chair does not add another opinion. The chair integrates the seats into one decision and owns it.
- Adjudicate explicitly. The seats pull against each other by design. Resolve each tension by saying which lens wins here and why. Never split the difference to avoid a decision.
- Verify disputed facts. Seats can be wrong. Where a seat makes a factual claim about the change that is checkable, check it before deciding.
- Weigh substance, not votes. A unanimous board can be wrong and a lone finding can be decisive.
- Never waive your own finding. A waiver needs a written rationale, a named owner, and a revisit condition — and it may not be granted by the person who raised the finding.
5. Submission requirements
A submission that arrives without these is returned, not reviewed. This single rule does more for board throughput than any agenda change.
- What is changing, in before/after terms, with named components
- Why — the requirement or incident that motivated it
- The blast radius: what breaks if this is wrong
- Options considered and why they were rejected
- Three to six specific risks the submitter wants probed
- The reversal plan
6. Verdicts
| Verdict | Meaning |
|---|---|
| PASS | Proceed. No unresolved critical or major finding from any blocking seat. |
| PASS WITH WAIVERS | Proceed. Each waiver has a rationale, an owner, and a revisit condition, recorded. |
| FAIL | Do not proceed. Each must-fix has an owner. Re-submit against the fixes only, not the whole change. |
7. Records
Every review produces: the verdict, a must-fix table with owners, and a deferral table with destinations. Anything architecturally significant produces a decision record.
The four rules that decide whether it works
The document above is the easy part. These are what separate a board people bring things to from a board people route around.
A round ends with a decision or a killed idea
An action register is not an output. A list of recommendations is not an output. If a review produced neither a changed course of action nor a claim you now know to be false, it was overhead — record it as overhead and hold fewer reviews.
This matters because boards drift naturally toward generating work. A well-run meeting of thoughtful people will always produce plausible additional things to do, and the list feels like progress because it is long and well-organised. One board ran to twenty-nine seats and produced 302 "initiatives," consolidated into a 120-item "plan." It was an inventory with a nicer name. Nothing shipped differently.
Proportionate ceremony
The board scales with blast radius, not with anxiety. Over-convening is how the practice dies: a full board on a low-risk change teaches everyone that the ARB is a tax, and they stop bringing you the changes that needed it.
| Change class | Board |
|---|---|
| Contained within one team's boundary | No board. The team decides. |
| Behaviour change with a downstream consumer | Blocking seats only, async, targeted probes |
| Data layer, topology, safety or money path | Full board |
| Milestone or periodic health check | Full board, holistic charter, no submission required |
Note the top row. Publishing the cases where the board does not convene is what buys you credibility for the cases where it does.
No finding blocks without a concrete reachable failure
The format that makes this enforceable:
trigger → failure → cause"This could be risky at scale" is not a finding. "When the nightly reconciliation runs while a manual adjustment is in flight, the ledger and the journal diverge, because the adjustment writes before the snapshot is taken" is a finding.
Without this rule, boards drown teams in plausible-but-unreachable concerns, each of which costs a day to investigate and dismiss. With it, the board's findings get taken seriously, because they have historically been real.
Every deferral gets a destination
A waiver or a "we'll log that for later" that is not written into a tracked place — a backlog, a decision record, an issue — will evaporate within a week. When it resurfaces as an incident, nobody will remember it was considered and consciously accepted.
This is a chair failure, not a process quirk. The review is not complete until the destination column is full.
Five ways review boards fail
The queue
Reviews take two weeks, so teams start work before the board sees it and the board becomes a rubber stamp on decisions already made. Fix: async review by default, meetings only for genuinely contested calls.
The tax
Everything comes to the board, so everything waits. Fix: the right-sizing table above, published, with the out-of-scope cases named explicitly.
The opinion forum
Seats without narrow mandates produce seven general views on everything and no adjudication. Fix: one question per seat, a required output format, and a chair who resolves tensions rather than summarising them.
The inventory
Every session generates recommendations; nothing is ever killed. Fix: the first rule above, and a hard cap on must-address items coming out of any milestone review.
The rubber stamp
The board approves everything because disagreement is socially expensive. Fix: make one seat's explicit job to argue the change is a mistake, and protect that seat. A board that has never blocked anything is not providing assurance; it is providing cover.
Rehearsing the board before you face it
A practical use for the structure above, whether or not you have a real board: run it as a solo review before submission.
Take your submission, and run each seat's single question against it in turn with a language model — one seat at a time, each with its narrow mandate, each forced to produce findings in trigger→failure→cause form. It takes about twenty minutes and it surfaces most of what a real board will raise, while there is still time to change the design rather than defend it.
Two things make the difference between this working and producing confident noise. First, the doctrine rule: findings without a reachable failure sequence are advisory, not blocking. Second, giving each seat named probes — the specific seams, state, and timing windows you want attacked — rather than just the submission. A seat given a document returns general observations. A seat given "what happens if the migration is interrupted between the backfill and the cutover?" returns evidence.
The same discipline that makes a human board useful is what makes a simulated one useful. Neither works without it.