One behaviour, three registers: fail-closed, a draft, a class, and a live question

2026-10-25 · RTTP · IQA

Reading the Draft · No. 13 · Sources cited in this piece · the draft, quoted verbatim: draft-kroehl-agentic-trust-aae-02 · its conformance vectors: aae-conformance-vectors · the live question: issue #189 · the W3C AI Agent Protocol CG list, October 2026 thread: 0015 · 0027 · 0031 · 0032 · our draft draft-li-rttp-iqa-addressing-00 · Sister pillars: RTTP (rttp://, CRI 27) · IQA (iqa://, CRI 28)

Some terms travel quietly for decades and then arrive all at once. Fail-closed — the discipline of treating a state you cannot verify as a refusal rather than a pass — is one of them. Within five months it has been written into an IETF draft as a MUST, carried as a data class in a conformance-vector suite, pre-registered on the W3C AI Agent Protocol CG list as experiment behaviour, and argued into a reporting-semantics rule. This piece credits each register by name, keeps the registers apart — because keeping them apart is the whole point — and then reads the live question the term has opened in issue #189 of the conformance lab.

Figure 1: one behaviour, three registers. The draft codified the rule, the vectors carry it as a class, and the wall argues it as semantics — three artifacts in five months, none of them owning the principle, each sharpening it.

The term, and why nobody owns it

Fail-closed is ancient engineering sense: a firewall with no rule denies, a circuit breaker with no answer opens, an airlock that cannot verify stays shut. When a check cannot complete, the default is refuse, not proceed. No standards body owns the phrase and none needs to — which is exactly why the interesting story is not who said it first but how precisely each register has lately stated it: which check, which failure, which refusal, and — the newest layer of the question — what the refusal should be called on a result sheet so that a third party can recompute it.

Register one: the draft, with our thanks

Lars Kersten Kroehl of CryptoKRI GmbH gave the term its agent-era MUST in the Agent Authorization Envelope draft: “If revocation status cannot be determined — for example, on network failure or an HTTP 5xx response — the relying party MUST reject the AAE.” Since July, his aae-conformance-vectors repository has carried revocation_status_indeterminate as a rejection reason of its own — the behaviour, expressed in data. Independent convergence is the strongest signal a design problem is real. We name the source, with respect.

Registers two and three: the wall

Our own registers are narrower, and they were staked on the CG list. In letter 0015 we pre-registered the behaviour for the lease-revocation experiment: in live-standing-read mode, the unreachable variant’s refusals are fail-closed — “an organ that cannot be reached is not read as silent consent.” In letter 0031 the point became reporting semantics: “A record that folds unreachability into a substantive reason manufactures an intent nobody had; keeping the two apart is what makes third-party recomputation meaningful.” And the bridge between the registers was built by Lars himself, in his opening mail quoted on the list (message 0027): “Lee’s fail-closed answer for the unreachable case already names the behaviour, and the result sheet should be able to show it.” Three registers, one conviction — and the citation chain runs in the generous direction.

A note on what the registers are not. The draft states a behavioural rule for its own envelope model. Letter 0015 pre-registered behaviour for one experiment. Letter 0031 argues a result-sheet distinction. None of these claims the principle; none needs to. The work is in the separation — a spec rule, an experiment expectation, and a reporting requirement are different artifacts with different scopes, and a conformance culture that blurs them will end up arguing about credit instead of arguing about vectors.

The live question in issue #189

Issue #189 on the lab’s repository now turns the conviction into two concrete questions. The first is mechanics: “I can supply a fixture for that case with the evaluation instant pinned in the vector, so the expected decision no longer depends on when it runs.” Welcome — and it completes a loop we care about. Our independent runner already refuses to score any vector file whose SHA-256 is not pinned in its manifest; a pinned instant extends determinism from bytes to time. Our own formulation, in letter 0032: “A score that moves with the clock is not a score; it is a reading.” We asked that sub-question on both venues, and it closed faster than this piece: about an hour after publication, Lars answered on #189 — absolute, in his words: “The verifier reads the instant from the fixture and never calls the clock, so the expected decision comes out the same on any machine and at any time.” The offset he declined, for the reason we would have given: “An offset would need an anchor both sides agree on, which adds a dependency a fixture does not need.” Determinism now runs from bytes through time, with no shared anchor slipping in through the back door — the smallest instance of the trust question this thread started with, closed in the smallest way.

The second is governance, and the restraint is as notable as the class: “Our set reports revocation_status_indeterminate as a rejection reason distinct from ancestor_revoked, and the existing taxonomy does not carry that class. Hence the question before a PR.” The repository’s own CONTRIBUTING asks candidates to stay inside the existing schema and taxonomy, so the adoption call belongs to the suite’s maintainer — and we have said so on the record, in the issue and on the list. What belongs to the list, per our letter of 24 October (message 0028), is the acceptance debate: the criteria for any common vector set are argued there rather than settled anywhere else. Mechanics to the repository; adoption to the maintainer; criteria to the list. Nothing about that division is ours to redraw.

Figure 2: the live question, divided by venue. The fixture is repo work, the class is the maintainer’s call, and the acceptance debate belongs on the list — a division of labour that keeps a conformance culture arguing about vectors instead of about credit.

A same-day addendum: the vectors themselves have been filed as PR #190 under the candidate route Lars announced on the list — byte copies pinned at 6bb462f, CHECKSUMS.sha256 with 64 entries behind the digest gate, deviations stated rather than smoothed over, and an evidence line that reads: “Author-produced only … No independent run exists.” The independent seat is named as empty, not silently assumed — which is exactly what this piece argues: keep the registers apart, and let every signature land where it belongs.

The attitude

Open protocols evolve and get updated — that is exactly why we gather to discuss and experiment together. The draft contributed the MUST. The vectors contributed the class. The wall contributed the semantics. The two schemes this blog carries — RTTP (rttp://) for where and when, IQA (iqa://) for whether — will meet revision 3 the same way our runner met revision 2: frozen inputs behind digest gates, a pinned evaluation instant, per-mode and per-axis scoring, and an artifact of record for anyone who wants to recompute the run. A fair experiment can score all three registers — and credit each one in its own name.

One line: one behaviour, three registers — a draft wrote it as a MUST, vectors carry it as a class, the wall argues it as semantics; keep the registers apart and credit each in its own name, because that separation is what makes third-party recomputation meaningful.