The Review Shift, and Real-World Texture

Overview

The previous topic established that an Architecture Board answers a review-capacity problem, and that the problem belongs to a much larger organisation.

That is about to stop being true, and headcount is not the reason.

The shift

Module 7 established what AI-assisted design changes: producing a candidate design gets dramatically cheaper, and evaluating one does not. The scarce skill moves from generation to validation.

Governance is where that lands, because governance is validation at an organisational level. The volume of designs needing review is a function of how cheap designs are to produce, and that has changed by a large factor while headcount has not moved at all.

So the capacity threshold that justifies distributed review arrives from the generation side. An organisation that comfortably supported one reviewer last year can exceed that capacity this year with the same number of engineers — which inverts the previous topic’s conclusion for exactly one mechanism, and leaves the rest standing.

Reviewing a generated design

The protocol differs from reviewing a human’s design, because the failure modes differ. A human’s design is usually weakest where they were uncertain, and the uncertainty shows. A generated design is uniformly confident, and fluency is uncorrelated with correctness — Module 7’s central point about one’s own work, applied to someone else’s.

graph TD
  A["<b>1 · Check the constraints</b><br/>were they in the input<br/>at all?"] --> B["<b>2 · Check the arithmetic</b><br/>plausible numbers that<br/>do not add up"]
  B --> C["<b>3 · Check what is missing</b><br/>generation omits silently"]
  C --> D["<b>4 · Check the<br/>justification</b><br/>reasons, or reasonable-<br/>sounding text?"]

  classDef one fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef two fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef three fill:#D9695B,stroke:#B4483A,stroke-width:2px,color:#ffffff
  class A one
  class B two
  class C three
  class D two

Four checks, ordered by how often they find something. The third is the hardest, because an omission leaves no trace in a document that reads as complete.

Were the constraints in the input? The most common and most consequential failure. A design that never saw the regional data constraint will produce a clean architecture that violates it, and nothing in the output indicates the omission. Check the input before the output.

Does the arithmetic hold? Plausible numbers that do not reconcile. Modules 4, 5 and 6 each turned on a figure that looked reasonable and did not survive multiplication.

What is missing? Generated designs omit silently — a degradation path, an audit requirement, a failure mode. There is no gap in the prose where the missing thing should be, which is why this check has to be driven by a list rather than by reading.

Is the justification reasoning or fluent text? Module 8’s mechanism-versus-conclusion test, applied here: a reason names a mechanism, and text that merely sounds like a reason names none.

What this means for the practice: review criteria must be explicit and enumerated, because an implicit standard cannot be applied at volume and cannot be distributed to anyone else. Which is also what makes cross-review possible — and cross-review is how the capacity problem gets solved without a board.

Real-world texture

Three conditions every practice meets. None is solvable; each is manageable.

Documentation is out of date. Always, everywhere. The Documentation-as-Code argument reduces drift and does not eliminate it. The practical defence is a status and a date on everything, so a reader can discount appropriately — a document known to be eighteen months old is usable, whereas one of unknown age is not. Trying to achieve fully current documentation fails; making staleness visible succeeds.

People resist process. Usually for good reasons: they have lived through process that cost them time and delivered nothing, and Module 1’s framework theatre is their evidence. The response is not persuasion but sequence — make the first thing you introduce immediately useful to the people it touches, and let adoption be the argument.

Tribal knowledge stays tribal. Some people will not write things down. Occasionally it is deliberate, because the knowledge is their position in the organisation; more often it is that writing is expensive and nobody has made it their job. Interviewing and writing it up yourself works and the previous section’s recovery discipline applies — mark it reconstructed. Waiting for them to write it does not work.

Where this leaves the module

The artifacts are a small set with defined lifespans. The process is collaborative discovery, documentation in the repository, and review criteria that are explicit enough to distribute. The governance is almost nothing at first, deliberately.

And the practice’s own success condition is the one from the start: it keeps working when you are not there.

When one reviewer stops being enough

The arithmetic that changes the previous topic’s conclusion, and it is worth doing because the answer is not where you would look for it.

About eighteen teams. Each produces something worth architectural review roughly monthly — a new integration, a boundary change, a significant dependency. That is about 18 reviews a month, and a review done properly against the four checks above takes around three hours. Roughly 54 hours a month: about a week and a half of one person. Comfortable. One reviewer, no board, which is what the previous topic concluded.

Now apply Module 7’s finding. Assisted design has made producing a candidate design several times cheaper, and the observed effect is not better designs — it is more of them. Options that would previously have been dismissed in conversation now arrive as documents. Take a conservative factor of three on volume: 54 hours becomes about 162 hours a month, which is more than one full-time person doing nothing else.

Headcount has not changed. Eighteen teams, 140 engineers, the same organisation. The review capacity threshold was crossed by generation volume, not by growth — and this is the one mechanism from the previous topic whose deferral the arithmetic overturns.

What it does not justify. Not a board — a board is a decision body, and this is a throughput problem. The fix is cross-review with explicit criteria: the four checks written down, and engineers reviewing each other’s designs against them, with the architect reviewing the ones that cross boundaries or touch the action path. That distributes the 162 hours across the people producing the designs, which is where it belongs.

And the condition that would justify a board: genuine disagreement about criteria, repeatedly, between teams that cannot resolve it. Not volume. That is the reversal condition, and it belongs in the record — which is the Section 1 discipline doing exactly the job it was introduced for.

Feeds the workbook

The four review checks belong in your process proposal as explicit criteria, and the capacity arithmetic is the argument for cross-review rather than a board. Your ADR set should carry the reversal condition for that choice.

Check your understanding

1. Run the capacity arithmetic for an organisation you know. Where does it land, and what would a factor of three do to it?
2. Take a design you did not write. Which of the four checks finds something?
3. Someone holds knowledge they will not write down. What do you do, and what do you not wait for?

---

→ Ten topics. Architecture is now a process rather than a person. — Module 10 — Evolving What Exists

Optional workbook: Exercise 9 turns this module into artifacts. The exercises build on each other, so work them in order or not at all.