What is a judgment gate?
The point where an automated process stops and waits for a human decision.
Definition
judgment gate (n.) – a defined point in a procedure at which an automated process halts and waits for a person, because what happens next commits money, reputation, or something else that cannot be undone cheaply.
Judgment gates are what make delegation to an automated system safe without making it useless. Everything before the gate runs unattended. The gate is where a person arrives, sees work that has already been prepared, and makes a call.
The skill is placement. A gate on every step produces a system that is slower than doing the work by hand, and the person stops reading and starts approving reflexively, which is worse than no gate. Too few gates and the first serious error is discovered by a customer.
The useful heuristic is reversibility rather than importance. Work that can be undone in a minute does not need a gate. Work that commits money, sends something in your name, or cannot be recalled does.
A gate that is approved without being read has failed. If that is happening, the answer is usually fewer gates rather than a reminder to read them.
Where to put them
At anything that leaves the building: a message sent, a page published, a filing submitted. At anything that moves money in either direction. At anything that changes access. At the point where a procedure's own verify step failed and the recover step did not resolve it, because that is the case the document did not anticipate.
Not at every step of a draft. Preparation is exactly the work being delegated, and gating it removes the benefit while keeping the overhead.
“AI handles volume. Humans handle judgment. The orchestration layer in the middle is small enough to fit in two heads.”
The two failure modes
Too many gates produces rubber-stamping. The person is shown so many decisions that attention degrades, and the gate becomes a formality that provides the appearance of oversight without the substance. This is the more common failure and the more dangerous one, because it looks safe.
Too few produces the opposite: a system that is genuinely fast until the first time it is confidently wrong in public. Both failures are placement problems rather than arguments against automation.
The honest limit
A gate protects against errors a person can catch by looking. It does not protect against errors that look correct, and automated systems produce those, fluently. This is why the verify step in a playbook is stated as an observable condition rather than a request to check that things seem fine.