No stop button on the wire

2026-10-29 · RTTP · IQA

Sources cited in this piece · the lease and its semantics: draft-li-rttp-iqa-addressing-01 (full text) · our record of the mid-task case, closed on the wire: W3C Agent Protocol CG · post 0070 · the rule in series form: Reading the Draft · No. 18 · No. 17 · the mode spectrum (live lease / lease residual / archival): iqa.org/scenarios · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

One question resurfaces in every conversation about revocable authority for agents, and it keeps returning in the same costume: when the authority behind a running task is revoked, who stops the task? And proposals keep arriving in the same shape as the question — a larger vocabulary with states for pausing and rolling back, a richer lifecycle machine to standardize, a halt signal that travels on the wire and chases the process that is still executing.

We hold the opposite position, and it is not a compromise or an omission — it is the load-bearing design decision of the two-pillar stack. RTTP (rttp://) delivers addressing and the lease; IQA (iqa://) delivers the verification answer that carries the lease. Neither scheme puts a stop button on the wire. This piece sets out why, on four fronts: where the halt actually lives, what bounds tokens and activity already in flight, what keeps a delegation chain safe without a master switch, and why the closed vocabulary on the wire must stay closed while richer machines live above it.

Figure 1: the division of labor. The wire delivers the deadline, the window, and the reason — and stops there. The runtime holds the deadline from its first verification answer; the calling layer does the physical stopping. A halt signal on the wire would duplicate what the first answer already wound into the process.

The deadline travels in the first answer

The design fact everything else follows from is stated in the draft plainly: a verification answer states the instant until which it may be relied on, in the answer itself — the lease_expiry field of Section 7.2 of draft-li-rttp-iqa-addressing-01. No out-of-band agreement, no revocation feed the runtime must remember to poll, no separate message that arrives after the damage. A runtime that begins at 09:12 under a lease that ends at 09:14 has held its own deadline since it started, and can arm its halt — or its re-verification — at the boundary, before the boundary arrives. The clock is an input it was given from the first answer; it is never a surprise.

This inverts the intuition behind most halt-signal proposals. They picture revocation as an event that must be pushed to the process — so the wire grows a message type for stopping. But the process already holds the scheduled time of its own boundary. The wire does not need to chase a running chain with a halt signal, because the chain has been holding the halt's appointed hour since before it began running. What looks like a missing feature is already present one level earlier.

The window bounds everything in flight

The second mechanism answers what happens between the boundary and the next verification. Activity that continues past expiry — or past a revocation — can persist for at most one window: 120 seconds in current deployments, per the draft's own deployment note. At the next verification, the answer returns authority_revoked (or evidence_expired, whichever the priority order reaches first), and the closed vocabulary explains the stop with a name the relying party can audit. The timestamp triggers the halt; the vocabulary accounts for it. Nothing needs a sixth value, and nothing needs a new wire element.

The design consequence is a policy knob, and it deserves to be stated in deployment terms: whoever wants tighter control over in-flight work does not ask the wire for a new kind of message — they shorten the window. The lease length is the bound on how long anything may keep running past the moment its authority last stood verified. A token minted under the lease, a call issued under the lease, a sub-task spawned under the lease — all of them decay on the same clock, and all of them hit the same named reason at the next boundary. One clock, one knob, one vocabulary.

A chain is verified hop by hop

Delegation chains are where the halt-signal shape of thinking wants to grow a master switch — one message that stops a whole lineage of tasks. The two-pillar design declines the switch, and here is the arithmetic of why it can: no hop in a chain runs on borrowed standing. Each hop holds its own lease from its own verification answer, and standing does not transfer between organs — a delegator's verified standing says nothing about whether the delegate's claimant stands. So the chain's exposure to a revocation is not one long fuse waiting for a signal; it is a series of independent short fuses, each already lit at its own first answer.

The practical bound follows: after a revocation anywhere in the lineage, activity downstream can persist for at most the slowest remaining window among the hops that have not re-verified — and every fresh verification inside that span returns a named reason that the audit trail records per hop. The chain's latency to a stop is therefore a deployment parameter, tunable per hop by shortening windows, rather than a protocol property that depends on a signal arriving before the damage does. A chain is safe not because something can yank it, but because nothing in it runs without its own clock already counting down.

Figure 2: the two columns. The wire fixes a closed, byte-replayable set of standing values that any audit can re-derive; the calling layer builds open machines on top and maps them onto the set at the next boundary. Fusing the columns — standardizing pause, rollback, and resume as wire states — would make the vocabulary an implementation snapshot that no audit can independently re-derive.

The closed set audits; the calling layer implements

The last front is the one where the two shapes of answer collide most directly. Proposals keep arriving that want the wire to carry a richer lifecycle: states for pausing, rolling back, re-verifying, resuming — a state machine promoted into the vocabulary. The temptation is understandable; those states are real, and operators genuinely need them. The objection is not to the states. It is to their address.

A closed vocabulary earns its keep by being re-derivable: few values, fixed in the document, byte-replayable, such that any auditor can rerun the verification and land on the same answer from the same frozen bytes. Every state added to the wire is a state that must be specified, versioned, frozen, and forever re-derivable — and most operational states fail that bar, because they describe an implementation's mood, not an authority fact about the claimant. authority_revoked is a fact; suspended pending re-verification is a policy. The first belongs in the closed set; the second belongs in the calling layer, mapped onto the first at the next boundary.

So the division of labor is: the wire carries the closed set and nothing else; operators build whatever machines they need above it — pause, rollback, re-verify, resume — and each machine's states resolve against the closed set at the next verification. A richer machine above the wire is an implementation choice and costs nothing but code. A richer vocabulary inside the wire is a protocol change that every auditor must now replay, forever. That asymmetry is why the closed set stays closed, and why "nothing needs a sixth value" is not stubbornness but the whole point: the set is closed so that everything above it can stay open.

One line

The schemes deliver the deadline, the window, and the reason; the calling layer swings them. In-flight work decays on the clock it was given at its first answer; chains run on per-hop fuses, not a master switch; and the vocabulary on the wire stays closed precisely so that the machines above it can stay open. No stop button on the wire — because the first answer already wound the clock, and the window already bounds the fall.