Gate What You Cannot Undo
A fail-closed gate whose indeterminate branch has no sanctioned exit is not a control but a ratchet, and the cure is to gate the irreversible consequence rather than the reversible disposition: reversible means the system decides and the operator audits against an undo whose reversal stood, irreversible means the operator decides and the system prepares the decision.
Most AI governance starts as a safety decision and quietly becomes a queue. Someone senior looks at what the system is about to be allowed to do, decides a human should sign off, and puts a gate in front of it. That is the right instinct. Six weeks later there are a couple hundred items behind the gate, the person who has to clear them has a full-time job that is not clearing them, and the work the gate was protecting has stopped moving.
Nothing in that story is a failure of the model, and nothing in it is a breach. That is what makes it hard to see. There is no incident and no bad output to point at, only a business outcome that was supposed to happen and did not, and a control everyone still describes as working.
I ran that failure in my own estate for months.
What the queue actually held
On 2026-08-23 my internal work board held 165 active items. I had built it to stop parallel AI sessions racing each other onto the same work, and at that it worked. As a picture of what needed a human, it was noise.
Of those 165, 100 were machine-generated findings from automated scanners that only ever report; by my own written rule they never authorize work. The remaining 65 were real commitments, and they had not moved at all, the oldest of them for 46 days. So three fifths of that surface could not authorize anything by design and the other two fifths had stopped. Not one item was unsafe. Not one was moving either.
The second gate, the one that should have caught it
Two gates were stuck here, not one. The approval gate queued behind me. A second was supposed to keep that queue honest without me reading it: a liveness check meant to notice when an item was dead and demote it.
It asked each item's source system whether the work had landed, using an identifier it does not accept, so the question never got an answer. The code then did what a careful engineer would write: it treated "no answer" as indeterminate and refused to act.
That refusal is correct. An infrastructure outage must never read as abandoned work. The direction of the failure was right.
What nobody measured was how often that branch was taken. Of the 521 items the board had ever held, only 216 carried a source reference the check could even attempt to read. For 213 of those 216, roughly 98.6%, the identifier was one it could not use. The remaining 305 carried nothing to read at all. The dead flag was never once true, and the board grew in one direction for months, while every individual line of that code would pass review.
A gate that is almost always indeterminate, with no way out, is not fail-closed. It is stuck.
A fail-closed gate refuses a specific thing for a stated reason. A stuck gate refuses everything because it cannot tell, and nothing can ever leave that state. It is a ratchet wearing a control's clothes.
The repair was not a weaker gate but a resolver that tries several ways to read the reference before giving up, so indeterminate became rare instead of universal. It narrows the way in. It never opens a way out.
The failure the analysis could not fix
Here is the part that generalizes past my board. Three separate analyses had already diagnosed it, in June, early July and late July. Each was correct. Each terminated at an operator gate that never fired: they ended in "Dan decides," and sat unfired for 58, 44 and 29 days respectively, until the change on August 23.
The bottleneck was never analysis. Analysis was abundant. The bottleneck was that every path ended at one person, and that person was the same person the queue was already waiting on. A fourth analysis would have been a fourth unfired gate.
If your AI governance routes every decision to one approver, that approver is your throughput ceiling, and no amount of better reporting into that queue will raise it.
Gate the consequence, not the disposition
The larger fix was gating a different thing.
Almost every item involved two separable decisions. The disposition: should this stay open, close or defer. And the consequence: what actually happens in the world. I had been gating both, and only one needs it.
The rule I settled on:
Reversible means the system decides and the operator audits, so disposition runs on its own. Irreversible means the operator decides and the system prepares, so publishing, merging to a main branch, deploying, spending money and mutating a secret stay exactly as gated as they were.
The safety property for the reversible half is not a human gate. It is a real undo. If you cannot reverse it in one step, it was not reversible, and it belongs on the other side of the line.
What the system owes you when it decides
Handing the reversible half to the system is only safe if the system pays for the privilege. Five properties, all checkable from artifacts rather than anyone's assurance.
A stated default per class of item. Not a model deciding case by case what feels stale. A written rule: an unactioned machine finding ages out after this many days, a commitment with no motion defers after that many. Written rules can be argued with; judgment calls cannot. This is also the exit out of indeterminate that the earlier check never had. A default that fires on the clock cannot be blinded by a probe that cannot tell.
An audit trail that names the actor. Every automatic change records which rule made it and when. Without that, "the system decided" is indistinguishable from "something happened."
An undo whose reversal stood. One command, scoped by actor and date. Be precise about the bar, because it is the one people skip: an undo you have designed is not an undo, and neither is one that got overwritten before anybody relied on it. It is also bounded, and the bound is the good part: it refuses to move an item whose state has moved on since, rather than clobbering the newer decision. This is the same standard the five-tests edition applied to recovery drills, pointed at a new target.
An ordering that cannot race the work. A live claim is never touched, so an automatic pass cannot dispose something already being worked, and escalation is evaluated before any automatic deferral, so a live risk cannot be quietly aged off by a rule that ran first. Order of evaluation is a safety property, not an implementation detail.
A closed list of what is allowed to interrupt you. Mine is four conditions: a pending irreversible action, a verified live risk, a genuine either-or, and anything I flagged myself, that last one applying to commitments rather than to machine findings, which reach me only on live risk. What matters is not my four, it is that the list is closed and written. Age does not qualify. Volume does not qualify. Topic does not qualify. Every queue that becomes a filing cabinet got there because those three were allowed to vote.
Notice what is not among those five: a review queue, a weekly summary, a dashboard. They tell you what happened. None of them is what makes the delegation safe.
The property I do not meet yet
One admission against my own standard, because I checked while writing this. My undo has fired exactly once, under 10 seconds after the disposition it reversed, and 46 seconds after that the next pass re-closed the item. That is a rehearsal against a board still moving, not a reversal that stood, so by my own undo property it does not count.
Why it did not hold is the useful part. Nothing the next pass reads told it the reversal was deliberate, so a considered reversal and a stray edit looked identical to it. The primitive already exists in the ordering property, since a claimed item is never touched, and the undo does not reach for it. I am not calling that a finished fix, because a claim only reserves an item for a while, it does not record why, and I have not worked through what that costs. It is a direction. What I can say is that the gap sits in the system rather than in my intentions.
The filter that flagged a third of the board
The escalation filter produced the sharpest lesson. Its first version flagged 55 of the 165 items as needing a human. Every match looked plausible in isolation. The tell was the rate: a filter that escalates a third of the corpus has reproduced the problem it was built to solve.
The cause was keyword matching over free text. The pattern for irreversible actions contained words like publish, send, deploy and launch, and it matched the names of background services. A scheduled job whose name contained the word publish read as a pending publish action. Service names were being parsed as verbs.
Two changes fixed it, and the larger is the less obvious. First, machine findings were made ineligible to escalate except on a live risk, because by the rule above they never authorize work; that alone accounted for 40 of the 55. Second, the irreversible-action pattern specifically was replaced with structural fields: an approval step that exists and has not fired, a status marking an item as awaiting sign-off, an explicit flag I set myself. Pattern matching survived only where a word names a condition rather than a topic.
Against the same 165 items, the rebuilt filter flagged 5.
What a leader can check this week
Four questions, all answerable from artifacts you already have.
What fraction of your AI queue can actually authorize anything? Separate the machine-generated findings from the human commitments and count them. If most of it is findings, you do not have an approval backlog. You have a reporting surface someone mistook for one, and the first fix is to stop routing it to a person.
How often does your gate land in "I cannot tell"? Not whether it refuses correctly, which is what reviewers check. Measure that rate against real items, not the examples in your tests. Then ask the question that matters: what is the sanctioned way out of "I cannot tell," and can anyone other than you take it? If the answer is "someone notices," you have built a ratchet.
For each thing behind your gate, is the consequence reversible? If it is, ask what would have to be true for the system to decide it and you to audit the result. The answer is almost always a working undo whose reversal stood, not a better dashboard.
Has any analysis of this problem already been done and not acted on? Count the days. Three correct diagnoses that never fired are evidence about your gate, not about your analysts. A human gate that never fires is an indeterminate branch in operator form.
Questions 2 and 4 test whether your gate is stuck, once in the machine and once in you. Question 3 tests whether it is on the right half of the work. Question 1 tests something the other three assume: that the queue needed a gate at all. If you only do one, do Question 1, because it is the one that can delete work rather than reorganize it.
What "prepared" means for the half you keep
A gate you decide to keep is a promise the decision will actually get made, and an approval arriving as a bare notification is not that. Prepared means the request already carries four things: the action in plain language rather than a job name, the evidence its preconditions hold, the cost of declining as well as accepting, and what reversal would take, or a plain statement that nothing can. That last one is the most decision-relevant fact in the request and the one most often left out.
The test takes ten minutes. Decide the oldest unapproved item in your queue using only what is attached to it. If most of your time goes to rebuilding context rather than weighing the choice, that queue is not slow because the decisions are hard. It is slow because the system is making the approver do its homework.
What it cost and what it did not fix
The first pass disposed the board from 165 to 81 that same day. As of September 1, after nine days of new work arriving and nine nightly passes, it was still sitting at 59, with a short brief each morning naming only what genuinely needs me. That morning's brief named three.
Three caveats, because a clean result is usually an incomplete one. Nine days is not proof of permanence. One of my four escalation conditions, the pending irreversible action, is detected by a structural field that nothing on the active board populated as of August 23. That is the same shape as the check this newsletter started with, a test that has never once come back true, and it fails in the worse direction: an unpopulated gate does not hold an item back, it lets the item defer on the clock. I am honoring it anyway so the filter sharpens as the data improves. Knowing the shape is not the same as being clear of it. And an item closes itself on landing only if its work is linked; 7 of the 165 were. The rest age out on staleness, a weaker signal wearing the same result.
One more receipt. This newsletter is late: three Mondays passed without an edition, because I had gated my own publishing pipeline behind me and then got busy. No alarm failed, because nothing about a late newsletter is unsafe, so nothing was ever built to catch it. The board got a disposition engine. The pipeline did not.
The bridge
If you are deciding what your AI systems may do on their own, the useful line is not how capable the model is. It is which of your outcomes are reversible.
For the reversible half, the work is the five properties above. For the irreversible half, it is making the decision arrive already prepared. That is the difference between governance that protects throughput and governance that consumes it.
You do not need me for the first pass. Take the workflow you would least like to explain to a customer, sort its outcomes into reversible and not, and see which half your gate is actually sitting on. If the line turns out to be in the wrong place, that is what the Readiness Scan my agency runs is for: one workflow, its failure modes mapped, and a plan for who owns it after launch. Work with OIA on one workflow.