What happens mid-task: the lease is the halt

Reading the Draft · No. 18 · Sources cited in this piece · the answer on the record, quoted verbatim: W3C Agent Protocol CG · post 0070 · the design rule it completes: post 0067 · the rule in series form: Reading the Draft · No. 17 · the lease semantics being applied: draft-li-rttp-iqa-addressing-01 (full text) · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

No. 17 ended on a design rule: the interpreter consumes the wire answer as an input and ranks what is permitted within it — it never overrules it. The same day that note went up, another colleague on the thread raised a case the rule had left implicit: a chain that starts inside its lease window and is still executing after the window has closed.

However the question was framed around it, the case itself is real, and it deserved an answer on the draft's own terms. We gave it the same day, in a follow-up note posted as a direct extension of the design rule — the answer being that nothing needs to be added, because the wire already carries everything the runtime needs, and the case dissolves into the two mechanisms the draft already defines. The note, in full:

Our reply on the record (post 0070), quoted in full · source on the wall
“One more case the design rule from my last note should cover explicitly: a chain that starts inside its lease window and is still executing after the window has closed. The wire already carries what that runtime needs. A verification answer states the instant until which it may be relied on, in the answer itself (the lease_expiry field, Section 7.2) — so 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. It is never surprised by the clock; the clock is an input it was given from the first answer. The window is also the revocation-latency bound. Activity that continues past expiry, or past a revocation, can persist for at most one window — 120 seconds in current deployments — and the next verification returns authority_revoked. The timestamp triggers the halt; the closed set explains it at the boundary. Nothing needs a sixth value for that, and nothing needs a new wire element: the same two mechanisms that answer boundary questions bound mid-task ones. The physical act of halting a running process remains enforcement, and stays with the calling layer — the same slot the draft leaves to action-time authorization. The schemes deliver the deadline, the window, and the reason; the runtime swings them. With this case spelled out the rule is complete: the interpreter ranks within what the wire allows, the clock bounds how long anything runs, and neither a model nor a mandate can extend the lease.”

The deadline is an input, not a surprise

The key fact is one the draft states 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 cache header, no out-of-band agreement, no separate revocation feed the runtime must remember to poll. 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. It is never surprised by the clock; the clock is an input it was given from the first answer.

This is the quiet inversion the mid-task case misses: what looks like a missing feature — "the wire tells me a call is refused, but nothing tells me to stop running" — is already present one level earlier. The wire does not need to chase a running chain with a halt signal, because the chain has been holding the halt's scheduled time since before it began running.

The window is the revocation-latency bound

The second mechanism answers the revocation half of the case. Activity that continues past expiry — or past a revocation — can persist for at most one window: 120 seconds in current deployments. At the next verification, the answer returns authority_revoked (or evidence_expired, whichever the priority order reaches first), and the closed five-value set explains the halt at the boundary with a name the relying party can audit. The timestamp triggers the halt; the vocabulary accounts for it. Nothing needs a sixth value for that, and nothing needs a new wire element — the same two mechanisms that answer boundary questions bound mid-task ones.

The design consequence is worth stating in deployment terms: a delegator who wants tighter mid-task control does not ask the wire for a new kind of message — they shorten the window. The lease length is the policy knob for how long anything may keep running past the moment its authority last stood verified.

Why this completes the arc

With the case spelled out, the design rule covers all three moments a delegation can pass through. Before any call: the envelope carries the mandate, unstandardized, and an interpreter of whatever kind may rank within it (No. 15). At each call: the wire answers whether the claimant stands, in a closed set of authority facts that an audit can re-derive (Nos. 16–17). And between calls: the lease bounds how long anything may keep running without a fresh answer, with the vocabulary explaining every stop at the next boundary. Three layers, one arrow of authority, no gaps left that a sixth value would fill.

The physical act of halting a running process — killing the task, revoking the session, cutting the loop — remains enforcement, and stays with the calling layer, the same slot the draft leaves to action-time authorization. The schemes deliver the deadline, the window, and the reason; the runtime swings them. That division is not an omission; it is the same discipline the whole series has been reading: the protocol delivers the knife and does not swing it.

One line: the lease is the halt — the deadline travels in the first answer, the window bounds how long anything runs past its authority, and neither a model nor a mandate can extend the lease.