Take a piece of knowledge work with ten steps in it and suppose each step is carried out correctly ninety percent of the time. Run it unchecked, one step feeding the next, and the reliability of the whole is roughly the product of the parts. Ninety percent, ten times over, is about thirty-five.
Put a checkpoint between the steps and an error caught at a boundary stops propagating into everything built after it. That is the mechanism, and everything practical here follows from it.
Two things are wrong with that arithmetic. It assumes the steps fail independently, which they do not, because errors cluster around a bad framing the way cracks cluster around a flaw. And it assumes the checkpoints catch what passes through them, which they will not, because every checkpoint has its own miss rate.
What survives both objections is enough. Gating shifts the decay from multiplicative towards additive. It does not take it to zero, which is why the engineering tradition this borrows from never relies on a single barrier.
So placement stops being a matter of taste. A checkpoint belongs wherever the cost of a propagated error first exceeds the cost of checking: the boundaries where a decision becomes load-bearing for everything after it.
A second rule gets missed. Models handle context flatly, while people re-weight continuously because they track what the work is for. So checkpoints also belong wherever that weighting shifts, at the point where somebody has to establish what now matters and what has stopped mattering.
The obvious risk is six checkpoints staffed by people who glance at the work and wave it on. That gives you six opportunities to rubber-stamp plus an audit trail implying a diligence that did not occur, which is worse than none, because now the organisation feels safe.
A gate is real when passing it requires the human to produce something the machine did not: a decision, a rejection, a reframing, a piece of context that exists only inside your firm. If the contribution can be discharged by approval, it is theatre, and it will decay into theatre within weeks whatever the process document says.
This is not hypothetical. In a training programme for a regulated life-sciences client, the work runs through five gated phases. Drafts are generated with one model, then attacked by a second running structured adversarial personas, an auditor, a technical specialist and a novice end user, before any human sees them. Every piece of machine feedback is then classified by a person as valid, already addressed, or wrong. And before anything reaches the subject-matter experts, the practitioner verifies each high-risk regulatory claim against the primary source rather than a summary, logging every check in a record that travels with the draft.
One model confirming another model's claim is pattern matching, not verification. The record is what the gate produces, and it is why the gate cannot quietly become an approval.
It also closed something I left open earlier in this series. If I do not know what you asked and what you checked, I cannot build on your work without rebuilding it. But a gate is a handover: the decision taken, the assumption made explicit, the thing rejected and why, is exactly the context the next person needs. The scaffolding around one person's work turns out to be the bridge to the next person's.
Three rules follow. Iterate inside a stage, never across the whole task, because one-shotting maximises the unchecked chain. Require generation, not approval. And measure what comes out of the sequence, never movement through it. Count gates passed and the artefacts become a genre of writing rather than a record of thought.
Something to try this week. Pick one workflow and install a single gate. One. Choose the point where an error first becomes expensive to reverse, and require that passing it produces one written thing the machine could not have produced.
You will know inside a fortnight whether it is real, because a gate that is theatre produces nothing anybody keeps.