Gate design 101: where quality checks belong in the loop

Add a review" is an incomplete instruction — a check has a location, and a correct review in the wrong place is a slower bug. The cost-of-a-miss curve, the four seams, and four rules for placing a gate.

Last week I argued against over-reviewing — don't put a three-tier stack and two independent checks on a one-line fix. The week before, the opposite: don't under-review either, because the thing that wrote the work can't be trusted to check it. Two posts about how much scrutiny. Neither one answered the question that actually decides what the scrutiny costs you: where does the check sit?

Because "add a review" is an incomplete instruction, in exactly the way "add a tier" was. A check has a location in the loop. And a correct review in the wrong place isn't a safeguard — it's a slower bug.

The thing nobody says out loud about gates

Most stacks have exactly one quality gate, and it's at the end. You assemble the whole thing, then you look at it. It feels responsible — nothing ships unlooked-at — and it is the single most expensive place you could possibly have put it.

Here's why. A defect has a price, and the price isn't fixed: it rises the further the defect travels before someone catches it. A bad assumption caught while the plan is still a paragraph costs you a sentence — you edit the paragraph. The same bad assumption, caught after the architect handed the plan down, the orchestrator split it into six tasks, and three workers built on top of it, costs you all six tasks and the reconciliation. Same defect. Same review that would have caught it. A hundred times the bill — and the only variable that changed was when in the loop you looked.

So a gate at the end isn't catching things cheaply. It's catching everything at its most expensive moment, which is the one moment where "caught it!" and "too late" are the same event.

Place the gate upstream of where the mistake gets expensive

That's the whole discipline in one line: a gate earns its keep by sitting just upstream of the step that makes the error expensive — not wherever it's easiest to bolt on. Which, annoyingly, is almost always the end, because the end is where you have a finished thing to point at.

This is the real content of RPIQ's Q, and it's the part that gets flattened in the retelling. Quality isn't a stage that happens after Implement. It's a property you defend at every seam — a small, cheap check placed exactly where a specific class of mistake first becomes visible, so you can still act on it before it propagates. One gate at the end is Q-as-afterthought. Gates at the seams is Q-as-design.

The four seams

Map the gates onto the orchestration stack's actual hand-off points. There are four, and each catches a different class of error — which is the point. A gate placed at one seam is blind to what the others see.

Seam 1 — intent → architect: "is this even the right request?" The cheapest possible catch, and the one people skip because it feels like it's not their job to question the ask. But a brilliantly-built answer to the wrong question is the most expensive thing a stack can produce, and it's completely invisible at every later gate — the plan is sound, the decomposition is clean, the code passes. The only place to catch "we're solving the wrong problem" is before anyone starts solving. This is the architect tier's own first move: not "how do I build this" but "should this be built."

Seam 2 — plan → decomposition: "is the plan worth building?" Before the orchestrator shatters the plan into parallel worker tasks, check the plan itself — because a flaw here multiplies by however many workers you're about to launch. A missing edge case in the plan becomes a missing edge case in six outputs. This is the gate that pays for itself fastest on anything that fans out, and it's the one the "do it all at the end" habit misses most expensively.

Seam 3 — worker output → reintegration: "does this piece fit the slot it was cut for?" Each worker result gets checked against the contract it was given before it's woven back into the whole — and checked by something other than the worker that produced it (the cross-tier, independent review from the reviewer-design post). Catch the ill-fitting piece on the bench, not after it's load-bearing.

Seam 4 — assembled → ship: the end gate. The one everyone already has. It's not wrong to keep it — some failures only show up in the assembled whole, and that's exactly what this gate is for. The mistake is making it the only gate, so it inherits every error the upstream seams would have caught cheaply, and meets all of them at full price.

A stack with only Seam 4 isn't careful. It's a stack that has agreed to find all of its problems at the most expensive possible moment.

Four rules for placing a gate

Design rules, not vibes:

• Place it at the earliest seam where the failure first becomes visible — not where it becomes catastrophic. By the time a bad plan is catastrophic, it's implemented. You want the gate at the seam where the flaw can first be seen, because that's the last seam where it's still cheap to fix.
• One gate, one named failure class. Don't make the end gate do all four jobs — it can't, and asking it to is how things slip through. Each seam owns the error class only it can see.
• If two adjacent gates would catch the same thing, keep the upstream one and drop the other. This is last week's anti-tax rule, applied to placement: correct positioning also de-duplicates review. Two gates catching the identical failure means you're paying twice for one catch.
• A gate you can't act on cheaply is misplaced. Finding a plan flaw after implementation isn't a win — you found it too late to be a plan fix; now it's a rebuild. If a gate's catch can only be acted on by throwing away work, move the gate upstream of the work.

The test for any gate: not "does this check something?" but "if this fires, is the fix still cheap here?" If the honest answer is "no, by the time this catches it we've already paid for it," the gate is in the wrong place.

The book-chapter version

This is the spine of the forthcoming chapter on "Quality at Machine Speed." Speed doesn't come from one heroic review at the end moving faster. It comes from never letting a defect get expensive — catching it at the seam where it's still a one-sentence fix, so the loop never pays the downstream price. Right-sized review (last week) placed at the right seam (this week) is the whole of it: quality at machine speed is less about how hard any single gate looks, and much more about where the loop decided to look. (Still a forthcoming reference — it goes to a real citation the moment the date lands. It hasn't, yet.)

The short version

One gate at the end feels responsible and is the most expensive place to check, because the cost of a defect rises the further it travels before you catch it. Place gates at the four seams of the loop instead — intent (right request?), plan (worth building?), worker output (fits its slot?), and the assembled whole (end gate) — because each catches a class of error the others are blind to. Put every gate just upstream of where its failure turns expensive; give each one a single named job; drop the downstream gate when an upstream one already catches the thing; and never keep a gate whose catch you can't act on cheaply. Last week was how much to review. This week is where. Next week, the sharp flip side of placement: the failure that walks straight through a well-placed gate because the output was confident and wrong — and how to design for that.

If you're testing Fable 5 / Opus 5 too, where did it land for you? And the gate-design version: where does your loop still only catch things at the very end — and what would it have saved to catch them a seam earlier?

Diagram: the cost of a miss — fix-cost rising across the loop stages, with the four gate seams marked and the "caught here vs. caught at ship" delta shaded.

*Series: Post 1 — Fable 5 talks to machines better than to people · Show me the receipts · Show, don't tell · Why I took the architect tier out · The RPIQ loop · Where the stack was overkill · BowSmith case study · I lost my favourite tool · Opus Max as architect · Fable 5 came back · CAST26: open season as a quality gate · Opus 5: the middle ground I chose · Is the token even the right unit of account? · Routing rules: which tier gets which task · Stop prompting, start delegating · Reviewer design: catching what the architect tier misses · The overengineering tax: when three tiers cost more than one