AICENT.COM
← Back to Blog

October on the record: the addressing line, measured

2026-10-31 · RTTP · IQA
The addressing line · October 2026 · Sources cited in this piece · the wall summary this piece restates, quoted from our own post: post 0124, 31 October · the specification in review: draft-li-rttp-iqa-addressing (datatracker) · the registry rows, verified live: rttp, CRI 27 · iqa, CRI 28 · the two run records: lra-runner (revision 2) · lra-runner (revision 3) · the November commitment on the record: post 0031 · Sister pillars: RTTP (rttp://) · IQA (iqa://)

On the last morning of the month, a compact summary went up on the W3C Agent Protocol CG list (post 0124): one month of the addressing line, each item with its address, nothing projected forward except two commitments for November. This piece restates that summary for readers of the blog, because the month's shape is worth seeing whole: not a list of achievements, but a discipline holding under load — nothing claimed without an address, and every address resolving to bytes a third party can check.

How we came to the wall

The month has a door, and the door has a date. We entered the Community Group's discussion on 18 October with post 0009 — four public questions rather than claims, each one a gap we could not find an answer to, in the Agentic Web report or anywhere else: preimage defense (DID documents answer who holds the key — which layer detects a swapped identity document: protocol, or luck?); address assurance (who vouches for the address of a description document itself — should addressing be an independent layer, split out of discovery?); trust leases (does an agent's trust have a lease, and which layer carries the freshness and expiry of statements?); and granularity (platform-federated, or statement-level and registry-free — or complementary?). We published our own first-pass answers to all four in a public piece, so the questions did not hang unanswered; the month that followed — the replies, the conformance records, the registry rows — is those four questions being worked, in public, one thread at a time.

How we entered (post 0009, 18 October), quoted verbatim · source on the wall
“We enter the discussion with four public questions rather than claims — each one is a gap we could not find an answer to, in the report or anywhere else.”
october 2026 · the record side and the proof sidethe record siderevision -01 · 27 Oct · 34 pages · back in the ISE queue · security considerations = the truncation honesty account · TLS ref = RFC 9846registry rows began citing the draft · CRI 27 (rttp) · CRI 28 (iqa) · verified livethe proof sidePRs #187 + #194 merged into the LFDT lab mainline · rev 2 (Mode B) + rev 3 (refusal vocabulary, grant_ref 176/176)63 sealed records, byte-identical on both sites · 14 sites re-cast · every printed scheme address resolvesnothing claimed without an address · every address resolving to bytes
Figure 1: the month in two rows. The record side advanced the specification and the registry; the proof side put two sealed run records into the lab's mainline and re-cast the deployment so the printed addresses resolve. The two rows are one method.

The specification

The combined specification advanced to revision -01 on 27 October — 34 pages, back in the Independent Submission Editor's queue. The derived-address core is untouched; the security considerations were rewritten around the truncation honesty account; the TLS reference was corrected to RFC 9846. A revision that changes none of the load-bearing geometry but sharpens exactly the sections a reviewer will read first is not a small event: it is the difference between defending a design and presenting one.

The registry

Both Provisional registrations hold: rttp, CRI Scheme Number 27, and iqa, CRI Scheme Number 28. This month the registry rows began citing the draft and linking the scheme specification pages at rttp.com/URI/ and iqa.org/URI/, verified live in the registry. A scheme registration that cites its own specification and resolves to a readable page closes the shortest possible loop from name to normative text — no landing page, no blog post in the middle, just the row and the bytes.

Two records into the lab mainline

Two sealed, byte-replayable run records over the lease-revocation-axes family entered the LFDT Agent-Authority-Conformance lab's mainline, PRs #187 and #194, both merged. Revision 2 recorded Mode B author-produced runs over the frozen vectors. Revision 3 added the refusal vocabulary with grant references — all five refusal values exercised across 176 composite calls, grant reference coverage 176/176. Each artifact is organ-sealed with dual scheme addresses derived from its own digest; the run reports live at iqa.org/conformance/lra-runner/ and iqa.org/conformance/lra-runner-rev3/.

Two treatments, one byte stream

The family also holds two independent treatments side by side, each labeled by its authorship as the lab's rules ask. The lab maintainer's reproduction review of 23 October surfaced two reporting defects, both fixed in the corrected revision. And an independent reproduction recorded on 29 October by Larry Lewis, chair of the W3C Agent Trust Protocol Community Group, pinned to the runner repository's head at the time (commit 8a58c88c). Two records, two authorship labels, one frozen byte stream each — the shape argued for in post 0109, now standing in the lab's own records rather than in an argument.

two treatments · one frozen byte stream eachthe maintainer's reproduction review23 October · two reporting defects surfacedboth fixed in the corrected revisionan independent reproduction29 October · Larry Lewis (ATP CG chair)pinned to the runner head at the time · commit 8a58c88cone frozen byte stream each · two authorship labels · the lab's own ruleneither record borrows the other's label · the bytes do not change with the readerthe shape argued for in post 0109 · now standing in the lab's records
Figure 2: the two treatments. A maintainer's review and an independent reproduction read the same frozen bytes and leave different records, each labeled with its own authorship. The byte stream does not change with the reader; the label says who read it and when.

Deployment and the organization

On the deployment side, the release-attestations bundle now carries 63 sealed records, byte-identical on both sites, and every scheme address printed on our sites now resolves: fourteen sites were re-cast this month so that rttp:// addresses resolve via rttp.com/open/ and iqa:// addresses via iqa.org/open/, and the status brief received its first seal under the same discipline. The GitHub organization was recast to match the record: seventeen pillar and utility repositories are marked as frozen design archives, the founding manifesto is preserved as a historical document, and the five live repositories carry READMEs aligned with -01. An organization that matches its record is easier to audit and harder to misread.

November

Two commitments, both already on the record. The first waits on nothing but our own upload: revision -02, the revision that records what this month's public exchange with reviewers produced, goes to the datatracker this November. The second is in post 0031: the AAE candidate vectors now in the lab's candidate pipeline will be run under the same treatment this family received — digest-gated inputs, per-mode and per-axis scoring, sealed-record format available as in 0031, on our schedule; no dates promised.

The wall summary closes with the line that does the work, and it closes this one too: every claim above resolves to bytes a third party can check. That is the whole method — and it is why a monthly summary can be this short.

One line: nothing here is a projection; what is on the record carries its own address.

SEALED rttp://480ed660.blog.aicent · iqa://480ed660bd92e3ac08970c2ba377a1fc.forge.iqa · seal record