What a revocation cannot recall.

Revocation is almost always specified as a state change — a bit flips, a list is reissued, a status reads revoked — and almost never as what it is, which is a claim about a set of actions. That set is not a property of the mechanism at all. It belongs to where the checks are, what they do when they cannot read the status, and whether anything still holds the action.

§1The question people ask, and the question they mean

Every discussion of revocation reaches the same question within minutes: how quickly does it propagate? It is the question with a number attached, and a number looks like an answer. The question underneath it is about consequences: what can still happen after the decision that it should not?

Take two systems whose distribution differs by orders of magnitude. If neither still holds the action when the withdrawal lands, both produce the same outcome and the speed bought nothing. Now take two whose distribution is identical, one re-checking at the last moment it still holds the action, the other only on admission. Those differ enormously. Propagation was constant; the set of actions that could still commit was not.

The instruments do not settle it. Regulation (EU) 2024/1689 requires, at Article 14(4)(e), that a provider enable a human overseer — as appropriate and proportionate — to intervene in the operation of a high-risk system or interrupt it through a stop button or a similar procedure allowing a halt in a safe state, with a suspension duty on the deployer at Article 26(5); both apply from 2 December 2027 for Annex III systems and 2 August 2028 for Annex I embedded ones.^[1] The voluntary NIST framework asks, at MANAGE 2.4, for mechanisms to supersede, disengage or deactivate systems performing inconsistently with intended use.^[2] Neither says which actions must not commit, nor where that stops being true.

Paper 005 §1 said of the credential answering who authorised this action? that its most important property is that it can be withdrawn, and then went no further. This paper is that follow-on, and it concedes at the outset that the property named there is not a property of the credential. A credential can express a withdrawal; what decides its effect is everything below.

§2Blast radius is a specification obligation

A withdrawal has to name what it withdraws, and the naming belongs in the specification rather than in the operator's head at the time. Three radii cover the cases that arise, and they earn their place by differing in kind rather than in size.

An unnamed radius is a defect rather than an omission, for reasons that worsen in order. The operator cannot state what they have just done, which is the first thing they will be asked. The record cannot state it either: an entry reading revoked with no named extent is not evidence a third party can check. And control cannot be graded, which is §6.

The named set is also only half of it, because the achieved reach is that set intersected with the enforcement points which actually consult the status.

§3Absence is not health

The substrate of Paper 005 §3 ends on a rule: every absence — a missing signature, an unloadable key — is a failure. Transposed to the live path it becomes the most consequential decision in the design. What does an enforcement point do when it cannot read the status at all?

The failure is undramatic. A point holds a status it fetched earlier, the distribution path stops working, and it now knows what was true earlier and nothing about now. Three behaviours are available, and one of them is a decision.

• Evaluate on the last status it could read. Failing open, with a specific hazard: an adversary who wants a withdrawal not to be honoured need not defeat the withdrawal, only make the status unreachable.
• Evaluate, and record a warning. Failing open with paperwork. The action commits; the warning is read by whoever investigates why it did.
• Refuse the actions whose cost of being wrong is unrecoverable. Not "refuse everything", which turns a status outage into a total outage and will rightly be switched off by the first person it wakes at night — but a decision made on the absence of evidence, which is the only kind available when evidence is what is missing.

the enforcement point asks one question: how old is the status I hold?

  within the refresh bound      →  evaluate   a decision made on evidence
  past the staleness threshold  →  refuse     a decision made on its absence
  status unreadable             →  refuse     the same decision, for the same reason

  evaluate anyway, on whatever was last read   ← the default that fails open

The cost is better stated than discovered: a fail-closed rule turns an outage in the status path into refused live traffic, and somebody will ask for the switch that disables it. That switch is the defect. What is legitimate is to bound the window in which refusal happens, which is §4.

§4The interval, honestly

An interval remains between the moment a withdrawal is decided and the moment every point that checks would see it. Two very different statements can be made about it, and they are routinely offered as the same kind.

A measurement describes one deployment, on one day, on a network that was behaving. It binds nothing — including the same system tomorrow — and it degrades in precisely the conditions under which it would be relied upon, since the interesting case for a withdrawal is rarely a quiet Tuesday.

A bound is a different object, and its force comes from enforcement rather than observation. "The status list is refreshed every T" is not a bound; it is a hope about a scheduler. The bound is no action of this class commits against a status older than T, enforced at the point that would otherwise commit it. Where a signed push sits above a scheduled refresh, the push is an optimisation and the refresh is the guarantee, because a push never delivered is indistinguishable, at the receiving end, from a push never sent.

§5The commit boundary

Everything so far shortens an interval. None of it addresses what the interval is an interval of, and that is settled by one decision: where the last check sits.

A check at admission answers was this permitted when we began? A check at commit answers is this permitted at the last moment we can still decline? For an action that begins and ends at the same point those are one question. For anything queued, batched, retried, scheduled or waiting on a person they are two, and only the second is about the present.

The rule that follows is short. Place a check at the last boundary at which the system still holds the action, and make it the full check. The qualifier is load-bearing: a re-check that consults a stored verdict from the earlier one is the earlier answer asked again. The defect shape is a flag on the action recording that it was authorised — exactly the artefact a well-meaning optimisation produces, and exactly what converts the one check that could have observed the withdrawal into one that structurally cannot.

One case holds the largest interval in most systems. When an action is parked for human approval the gap runs to minutes and sometimes hours, and it is the gap most likely to overlap a withdrawal, for an unglamorous reason: withdrawals are decided by people too, and people decide during the same working day. Re-running the full check at the moment of approval closes it — an approval granted after a withdrawal does not commit.

A refusal at any of these points should be written — what was refused, and which authority failed — into the organisation's own signed chain, on the substrate of Paper 005 §3. The dispute that arrives later is rarely was it withdrawn; it is what was still allowed to happen afterwards.

§6The widest lever needs two hands

A withdrawal is also something somebody writes, and writing it is a privileged operation whose danger scales with exactly the radius §2 insisted on naming. Turn the organisation-wide radius around: a mechanism that can withdraw every authority in an organisation can halt that organisation's automated operations on the strength of one credential. It is not only a safeguard; it is the most attractive attack surface in the system, because it needs no exploit at all — only the credential, used exactly as designed.

• The narrow radius stays single-control, deliberately rather than as a concession: the urgent ordinary case must not need a committee, and its blast radius is bounded by construction.
• The durable radii require a distinct second approver, and the distinctness is the entire property. A second approval from the same principal, a shared account, or a service credential held by the same process is an audit row rather than a control. It belongs in the specification as an inequality between two identities, not in a runbook as a procedure.
• The durable radii should be appended to a transparency log and return an inclusion proof (Paper 002 §6), because the contested question afterwards is usually when — and Paper 004 §6 applies in full: the operator's own timestamp on the operator's own log still wants a witness.

Dual control adds a step to the action one least wants to slow, and there are two answers. The bad one is a break-glass path around the second approver — a single-credential route to the widest radius, under a name that sounds careful. The good one is the grading itself: the narrow radii exist so that the urgent case is a narrow one. If containing a failure routinely requires the organisation-wide lever, the radii were drawn in the wrong places.

§7What withdrawal cannot recall

Withdrawal has a floor, and the floor is not latency. It is custody. Once an action has left the last enforcement point that held it — a request already dispatched to a downstream tool, a response already streaming, a batch already handed to a provider, an instruction already accepted by a counterparty's system — no withdrawal reaches it. Not a faster one, not a better-distributed one, not one decided a moment after the event rather than a minute after it. The boundary is not when did we learn; it is do we still hold it. Everything §3 and §4 buy is bought inside that boundary, and none of it buys anything outside.

Exactly one instance of the in-flight case is closed in the code these notes draw on, and it is worth describing precisely, because the temptation is to present it as the answer. The re-verification at approval described in §5 closes the interval between parking and approval — often minutes, sometimes an hour — and for a specific reason rather than a general one: that is the interval a person spends deciding, which is the interval most likely to overlap another person deciding to withdraw. It closes nothing else.

The limits, collected, because a reader deciding whether to rely on this class of control is entitled to them together rather than scattered:

1. Custody is the floor. Beyond the last point that holds an action, no improvement in distribution reaches it.
2. Coverage is an inventory claim, shadow mode is absence of coverage, and the inventory decays unless it is deliberately held.
3. One in-flight interval is closed — parking to approval — because the system had been asked to wait, not because the general problem was solved.
4. Graded control is only as good as the distinctness of the identities it rests on.
5. Withdrawal ends authority; it does not undo consequences. What was done under an authority valid at the time remains done, and unwinding it is a matter for people, argued from records — which is why the record layer of Paper 005 sits apart from the authority layer.

None of these is an argument against building the mechanism; a withdrawal that closes the intervals it can close is worth far more than one that closes none. They are arguments for describing it as what it is. The temptation here is to answer a question about consequences with a number about speed, because the number is available and the honest answer is a diagram of where the checks are. The number will be believed, and then tested against an action that had already left.

§8Provenance, and what is out of scope

The mechanisms described here are implemented in two systems built by the practitioners contributing these notes: an agent-authority layer (SignWard), which withdraws authority at the three radii of §2, and a policy gate (Gateward), which can refuse a call before it reaches a provider. The defect in §6 was found by adversarial review across both, which is the only reason it was found at all — each half looked correct to the people who had built it.

A third system in the same estate is named only to say what it is not. The governance layer of Paper 005 (RiverAct) names which duties attach to which system on which date, records the decision and computes the resulting deadline. It sits in no request path and it refuses nothing. Saying so is the same discipline as the rest of this paper: a layer that cannot intervene must never appear in a sentence about intervention, however convenient the adjacency.

Out of scope, here as throughout the series: the content of any rule, the language rules are written in, the shape of any record, the identifiers involved, and every operational specific. What is present is the part a sceptic can check — that a withdrawal is a claim about a set of actions, that the set is fixed by where the checks are and what they do in the dark, and that underneath it lies a floor made of custody which no mechanism described here crosses.