AICENT.COM
← Back to Blog

The condition and its facts: what a delegation's DENY stands on

2026-10-29 · RTTP · IQA
Reading the Draft · No. 19 · Sources cited in this piece · the correction on the record, quoted verbatim: W3C Agent Protocol CG · post 0081 · Alan Karp · the case it corrected: post 0067 · our reply, on the record: post 0082 · the mid-task rule it extends: Reading the Draft · No. 18 · the lease semantics being applied: draft-li-rttp-iqa-addressing-01 (full text) · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

The exchange that produced Nos. 15 through 18 did not stop at the mid-task case. The same counterpart — Alan Karp, whose questions have driven this series since No. 15 — came back with a correction, and it was the useful kind — the kind that redraws a boundary instead of disputing one. Our concrete case in post 0067 — an envelope reading “Book flights only within the company, through Friday,” an interpreter saying permitted while the wire says evidence_expired — had read “within the company” as a constraint on the action. The reply said, in its first sentence, that this was not the point:

The correction on the record (post 0081), quoted in full · Alan Karp · source on the wall
“Your example doesn't capture my point. When I said the condition is “within the company,” I intended it to mean to whom you should delegate. Let me use a slight variant of an actual case. One quarter HP had to release its financial statement early because a reporter was included on an email with a draft of it. Change the example slightly to delegating access to the draft.
We typically use labels, such as Company Confidential, to represent what might be a complicated policy. (Should external accountants hired by the company be included?) However you do it, it would be nice if the delegator could tell the delegatee (not a word but doesn't get confused with the verb delegate), what policies are appropriate for the permission. It's a “Please” because the delegatee may have a good reason to violate the request, e.g., to delegate to an internal program that doesn't have credentials.
As to your question about whether to honor the request, I would say DENY if any condition isn't met.”
the correction · the condition was about the delegation, not the actionDELEGATORaccess to a draftDELEGATEEwho may hold itcondition: "within the company"constrains the target · to whom the permission may travel · not what may be donetarget inside · the grant travels · label rides along as a "Please"target outside · the reporter on the draft · the leaka delegation that reached a principal the condition was written to exclude · the real shape of the incident
Figure 1: the correction, drawn as a delegation. The condition “within the company” does not sort actions — it sorts targets: to whom the permission may travel. The HP incident was not a policy misread; it was a delegation that reached a principal the condition was written to exclude.

A condition is not the fact it consumes

The aside about external accountants is the honest part of the note, and worth keeping in view: whether someone counts as “within the company” can be as complicated as the label suggests, and the Company Confidential sticker stands in for a policy only policy can finish drawing. That boundary is not ours to standardize — it is the same “Please” Nos. 15 and 16 already placed one layer up, and the correction leaves it exactly there.

But a condition and the facts it consumes are different commodities, and the distinction decides whether the whole construction can be audited. Whoever the delegatee is — and whether that delegatee's authority stands verified at the instant of use — are not policy questions. They are bytes a verifier returns. A DENY computed over those facts can be re-derived by a third party from pinned inputs, the same way our refusal reasons can; a DENY computed over the label alone is an opinion wearing a verdict's clothes. The condition may be as complicated as policy makes it; the facts underneath it are cheaper than the condition — and they are the only part a later audit can stand on.

Three lines that do not compete

Our reply (post 0082) accepted the correction and proposed the split the two positions had been converging on anyway. The delegator's “Please” travels with the permission, unstandardized, one layer up — the correction itself keeps it there. The DENY-if-any-condition-isn't-met executes in the calling layer; that is where the delegatee's good reason to violate the request — the internal program without credentials — gets weighed, because that judgment is the calling layer's, not the wire's. And the wire's job is the third line: to make the authority-side inputs of that decision checkable at the moment of use, not only at the moment of grant.

Nothing in the schemes needs to move for this. The draft never claimed the policy slot, so a condition on the delegation target takes nothing away from it; the five-value refusal set keeps answering whether, one layer below the “Please”; and the “Please” keeps its unstandardized freedom precisely because the floor under it is deterministic.

Grant-time or every-use

One question was left open, and it is the one we suspect the two sides see differently: does “within the company” have to hold when the delegation is made, or at every later use? If the answer is grant-time only, the condition is a signature on a moment, and whatever it checked is whatever the audit will ever see. If the answer is every use, then the employee who leaves on day thirty walks straight into the mid-task case of No. 18: the lease expires, the next verification returns authority_revoked, and the halt is armed by a timestamp the runtime has held since its first answer.

grant-time or every-use · the question the condition must answerday 0 — the delegation is made · the condition checks · the delegatee is insideday 30 — the employee leaves · the fact changes under the standing grantgrant-time only · the condition signed a momentthe stale fact rides to the end of the grant · no record says otherwiseevery use · the next verification returns authority_revokedthe stop is named · timestamped · re-derivable from pinned inputsthe condition is the delegator's · the freshness of the facts it consumes comes from the wire
Figure 2: the open question, drawn on a calendar. If the condition binds only at grant-time, it signed a moment and the stale fact rides silently. If it binds at every use, the day-thirty departure is exactly the mid-task case of No. 18 — and the stop comes back named, timestamped, and re-derivable.

The deployment consequence is the same knob No. 18 already turned, pointed at a new dial. A delegator who wants a delegation condition to ride on fresh facts does not ask the wire for a new kind of condition — they shorten the window. The lease length is the policy knob for how long any condition, on the action or on the delegation, may keep running on facts its grant-time check last saw. The condition may be theirs; the freshness of what it consumes has to come from somewhere, and the somewhere is the answer the wire already gives.

Why this round helped

The correction improved the map, and it cost one sentence. It split “policy” into two questions the draft never conflated — what may be done, and to whom the permission may travel — and showed that both live on the same layer, consume the same facts from below, and inherit the same audit rule: neither can be audited on its own say-so. It also produced the round's quiet convergence: a DENY is an enforcement act for the calling layer, the “Please” stays unstandardized where both sides placed it, and the wire keeps doing the one thing neither policy nor label can do — stating, in bytes, who stands and until when.

One line: the condition is policy and the fact is the wire — a delegation may be denied on a condition, but it can only be audited on the facts.

SEALED rttp://c28fb982.blog.aicent · iqa://c28fb982c9c9ad30c05b8b8a849afe9f.forge.iqa · seal record