The Agent Semantic Layer

Reader's guide — the two registers of this document.

This whitepaper speaks in two clearly separated registers.

The engineering register makes only claims a third party can verify without asking us: published specifications, registry entries, test vectors, packages on four platforms, and a public record with dated, hash-committed entries. Every number in this register is traceable to the sources listed in Appendix A and reconciled in the per-chapter source tables.

The narrative register (Chapters 5 and 6) presents lineage and forward scenarios. It is explicitly labeled, its historical corpus is frozen and hash-committed (Appendix C), and it deliberately contains no performance claims. Where narrative speaks, it says so.

The two registers never borrow each other's authority. That separation is not a stylistic choice — it is the same discipline the architecture itself applies to its two channels, and Chapter 3 explains why.

Abstract

Autonomous agents are beginning to transact with each other and with the physical world faster than the Web's lookup-and-fetch model can carry them. Two structural gaps have opened. Addressing: a URL states where a resource lives, but an agent often needs to name what a party is to do — computable, offline, without asking a registry. Standing: a TLS session asserts a connection is encrypted, but an agent needs to know whether a counterparty is authorized — portable, verifiable away from the network that issued it.

This paper presents a two-scheme answer. RTTP (rttp://), the Resonant Time Transfer Protocol, addresses intent: an rttp URI is a fingerprint derived from the authority itself by a single SHA-256 computation — no DNS, no registry query, no network call. Its name is a claim: intent addressing under a real-time constraint, kept by structure rather than by benchmarks. IQA (iqa://), Identity Quality Assurance, attests standing: an iqa URI asks a named Organ for a verdict about a subject — one of a closed four-state vocabulary, sealed with HMAC-SHA256 over the canonical claim and verifiable offline, with no issuer contact and no key directory.

The two schemes answer three different kinds of questions — where, when, and whether — and are deliberately kept in two namespaces so that computation never depends on anyone's word, and attestation never pretends to be computation. Both are specified in a single combined Internet-Draft in the Independent Submission stream; rttp is registered in the IANA URI Schemes registry (Provisional, CRI 27) and so is iqa (Provisional, CRI 28, added 2026-10-13); reference implementations ship on PyPI, npm, crates.io and GitHub with a 35-vector byte-for-byte conformance challenge that anyone can replay in any language.

The paper closes with lineage and horizon: the frozen Aicent Stack narrative from which the two pillars were carved (AICENT-000 through AICENT-015, hash-committed), and five vertical scenarios — fleet, energy, industrial, payment, swarm — where the constrained world turns the pillars' native properties from advantages into necessities.

Don't take our word for any of it — replay the vectors at iqa.org/challenge/ or run the demos at iqa.org/demo/.

Contents

1. The Epochal Shift — HTTP as dumb pipe · the two vacuums · the 2026 landscape · demarcation
2. Intent Addressing: rttp:// — the fingerprint law · the name is a claim · wire economics · verifiable now · security disclosure
3. Standing Attestation: iqa:// — parsing is not attestation · the standing vocabulary · portable standing · organs and dispute · security disclosures
4. The Dual-Pillar Equilibrium — "I QA" — I, the Answerer · the evidence chain · the constrained world · roadmap
5. Lineage: The Aicent Stack — genesis to freeze · the roll call (AICENT-000–015) · the fence · numbering note
6. Vertical Scenarios — fleet · energy · industrial · payment · swarm

Appendix A — Specifications and registry index Appendix B — The public vocabulary Appendix C — Hash lineage and recomputation

Chapter 1 — The Epochal Shift

1.1 HTTP as Dumb Pipe

The history of the Internet's transport layers follows a pattern: a protocol built to carry rich semantics is gradually drained of them as the layers above specialize. TCP did not die; it sank. It became shared plumbing beneath HTTP, and nobody asks TCP what a packet means.

HTTP/HTTPS is now repeating that fate. It remains indispensable as transport — and is simultaneously being pushed down into the role of a shared pipe by a new class of client: autonomous agents. An agent transacting with another agent, or commanding a device, does not want a page. It wants three things the URL was never designed to carry:

1. A name for an intent — what the counterparty is to do — as opposed to an address for a resource somebody has.
2. A portable assertion of standing — whether the party across the wire is authorized at all — as opposed to a session that is valid only while the connection lives.
3. Both at machine speed and machine scale — millions of micro-transactions that cannot each afford a lookup, a handshake with a registry, or a page fetch to learn anything at all.

The Web's answering machinery — DNS, registries, certificate authorities, session stores — was built for human-scale browsing: documents, fetched by people, at a pace where a round trip is invisible. Agent traffic inverts every one of those assumptions.

1.2 The Two Vacuums

Out of that inversion come two distinct structural gaps — and they are different kinds of gaps, which is why one protocol cannot close both.

The addressing vacuum. Traditional URLs bind naming to lookup: resolve a name, fetch a representation. But an intent is not a document. Two parties who agree on an authority should be able to compute the same address for what is to be done — offline, deterministically, with no third party's cooperation. No deployed naming system offers this; DNS offerings depend on resolution infrastructure, content addresses (IPFS and relatives) derive from the bytes of a blob rather than from the identity of an authority.

The trust vacuum. TLS proves a channel is encrypted and a certificate chains to a root. It says nothing about whether the subject on the other end is authorized for what is about to happen — and it says it only for the lifetime of the session. Agents need standing that travels with the subject: verifiable offline, bound to the subject's own key material, decoupled from whichever transport happens to carry it.

Source note (Ch. 1). Vacuum framing per working outline §1.2; content-addressing distinction reconciled with AICENT-002 §4.4 (derivation from authority, action-independent — an address is where, not what).

1.3 The 2026 Landscape

The gaps are not forming in a vacuum of their own; a generation of agent protocols is forming around them, and each holds a different piece:

• MCP connects agents to tools. It standardizes the interface a tool exposes. It does not address the parties, and it does not carry standing.
• A2A routes tasks between agents. It standardizes the exchange. The identity of the parties is configured around it, not computed inside it.
• agent:// (recently tightened in its own registration work) addresses agents as agents. It is the nearest neighbor in naming — and precisely for that reason it stops where the semantic question begins: it does not name intents, and it carries no attestation.
• RFC 9315 (SDDL) established that digital intent is a first-class semantic object with structure and scope. It is complementary work: it defines the semantics of intent; it deliberately leaves open how an intent is named and addressed on the wire.

The half-line positioning follows from the map: MCP connects tools; A2A routes tasks; we address and attest the parties themselves.

1.4 Demarcation: What "Semantic Layer" Means Here

The phrase "agent semantic layer" requires one paragraph of fence, because "semantic layer" is already occupied in the data-stack world (dbt and relatives), where it names a metrics layer between raw tables and business intelligence.

That is not this. Here, the agent semantic layer is the layer at which agents address and attest: the naming substrate on which an intent becomes an address (Chapter 2) and the attestation substrate on which a party's standing becomes a verifiable answer (Chapter 3). Metrics aggregate what happened; this layer makes machine-to-machine action nameable and authorizable in the first place. The two usages share a word and nothing else.

Source note (Ch. 1). MCP/A2A/agent:// demarcation reconciled with Constitution §A.6.8 (related-work doctrine); RFC 9315 framing locked to the "complementary problem" position agreed for the combined I-D's related-work section.

Chapter 2 — Intent Addressing: rttp://

2.1 The Fingerprint Law

Address is intent fingerprint.

An rttp URI names an intent against an authority. The address is not assigned, not resolved, not minted by anyone — it is derived:

canonical_authority = intent.pillar.root        (lowercase ASCII)
ROUTE_SHARD         = SHA-256(ASCII(canonical_authority))[0:16]

Worked example, using the Internet-Draft's own example authority:

authority     : f3b2a1c4.pillar.example
ROUTE_SHARD   : 557c8154d3780cb78cc5fa1bd72b331c

Any party — the sender, the receiver, a auditor with no network access — computes the same sixteen bytes from the same authority string. The consequences are structural:

• Zero network calls. No DNS, no registry, no dereference in the addressing step itself. The URI is the answer to "where", not a pointer that must be chased to produce one.
• Determinism. Same authority, same address — every time, on every platform, in every implementation. This is what makes the address a fingerprint rather than a handle: it is a property of the authority, not a record about it.
• Action independence. The derivation takes the authority only. The same authority under different intended actions yields the same address: an address is where, not what. (Content addressing is a relative, not a twin: it derives from the bytes of a blob.)

The complete grammar of the URI form — the ABNF for authorities, intents and actions, published verbatim from the Internet-Draft — is normative at rttp.com/URI/ and is not reproduced here.

Relative to RFC 9315, the positioning is one of extension, not replacement: SDDL established the semantics of intent; rttp extends the intent concept to the naming layer, which RFC 9315 leaves open.

2.2 The Name Is a Claim

The name Resonant Time Transfer Protocol is not decoration. It carries the protocol's second commitment, and the two halves of the name are one claim:

Intent addressing under a real-time constraint — addressing by intent, synchronized in time.

"Time transfer" is a real engineering discipline: keeping distant clocks in agreement without a shared wire. RTTP borrows that discipline for intent — two parties compute the same address into agreement without a shared lookup. And the temporal half of the commitment is kept by structure, not by benchmarks:

• Resolution is computation — one SHA-256, zero network calls — so the latency of addressing an intent is bounded, and it does not scale with the network. Growing from a thousand authorities to a billion does not lengthen the derivation by one clock cycle.
• This is a structural claim about where addressing latency comes from, not a performance benchmark, and it makes no comparison with clock- synchronization protocols (PTP's discipline is synchronizing clocks; it remains PTP's own).

Without the time constraint, computed intent addressing would be little more than an agent DNS — a cleverer way to find things. With it, the naming layer is aligned with the tempo at which agents and machines actually act. The two halves are one claim.

2.3 Wire Economics

The registry reality, stated exactly. rttp is registered in the IANA URI Schemes registry as Provisional, with assigned CRI 27 (allocated in the expert-review range), completed 2026-09-22 with designated-expert approval. The companion iqa is likewise registered (Provisional, CRI 28), added 2026-10-13. Nothing beyond that is claimed anywhere in this paper.

What CRI 27 buys is optionality on constrained paths: CBOR-encoded CRI carries the scheme in roughly one byte instead of the four-character scheme name — an economy that matters only when every byte is billed, which is exactly the regime Chapter 6 describes. The honest framing per the project's own doctrine: a short number is a compression win, not a technical advantage — paired schemes throughout registry history are rarely adjacent (ws/wss sit at 11962/3119), and adjacency is coincidence, not entitlement.

The attestation envelope (AE-128) — shipped in v1.3.1. The answer side enjoys the same economy: a fixed 128-byte envelope, live in the v1.3.1 packages of all three registries since 2026-10-05 (companion draft v0.3). The published layout — fixed offsets, no parser required beyond a hash function:

Offset  Len  Field          Description
  0      4   magic          'IQAE' (IQA Envelope — scheme-anchored)
  4      1   version        0x01
  5      1   algorithm      0x01 = HMAC-SHA256 (crypto-agility exit)
  6      2   flags          unassigned in version 1
  8      8   lease_expiry   u64 BE Unix seconds — verdict valid until
 16     16   intent_shard   ROUTE_SHARD of the subject (§2.1)
 32     32   attestation    HMAC-SHA256 over the ENTIRE frame,
                            with the attestation field itself zeroed
 64      8   organ          8 octets of US-ASCII organ tag
 72      8   nonce          u64 BE — unique per verdict issued
 80      1   standing       verdict state — the closed set of §3.2
                            (0x00 Ghost · 0x01 Probation ·
                             0x02 Radiant · 0x03 Genesis)
 81     15   reserved       MUST be all zeros
 96     32   extension      MUST be all zeros in version 1
                            (version bump, not TLV, governs evolution)
──────────────────────────────────────────────────────────────────
128 octets exactly — one frame, one datagram, under any MTU

Three properties are worth pausing on. Full-frame coverage: the HMAC is computed over the whole frame with the attestation field zeroed — organ tag, nonce, lease and standing are authenticated too, so a rewrite of the named answerer or a flip of the verdict state cannot survive verification. Same shard, two carriers: the 16 octets at offset 16 are the same ROUTE_SHARD the rttp side carries — one subject, one derived address, two envelopes; the question and the answer physically meet in the same bytes. Zero-parser verification: a receiver needs only SHA-256 and fixed offsets — no CBOR decoder, no TLV walker — which is the differentiation against sealed-object formats that require a parsing stack.

It is shipped: three zero-dependency implementations, byte-exact vectors replayed in every CI suite, and the full published vector set — positive, negative and tampered frames — riding inside every package. The question and the answer now each have a wire form:

        ┌──────────────┐            ┌──────────────┐
        │  rttp side   │            │   iqa side   │
        │ pulse frame  │            │   AE-128     │
        │ shard @0x36  │            │ shard @0x10  │
        └──────┬───────┘            └──────┬───────┘
               │      SAME 16 OCTETS       │
               └────────────┬──────────────┘
                            ▼
              one datagram carries WHERE, WHEN and WHETHER

2.4 Verifiable Now

Every derivation claim above can be replayed today:

• The 35-vector conformance challenge at iqa.org/challenge/ — any language, judged byte for byte. The vector set ships inside every package under a published digest (sha256 4b743e63…), and the terms are explicit: write an implementation from the specification alone, do not read our code, replay all 35. The set is tiered —

Passing all 35 earns a listing as an independent implementation — and a faithful reading that fails is our bug: the specification or the vectors get fixed, credited by name.

• The derivation demo at iqa.org/demo/derive/ — the browser and an independent derivation service compute ROUTE_SHARD separately and match, byte for byte, live.
• Packages on four platforms, all at 1.3.1 — PyPI rttp / iqa-org, npm @aicent/rttp / @aicent/iqa, crates.io rttp / iqa-org — with GitHub CI re-asserting the published self-test counts on every push (rttp 80/83 · iqa 108/111). The AE-128 vector set (ae128-vectors-v1.json — 1 positive, 11 fail-closed, 7 tampered frames, one sha256 across all three languages) ships inside the v1.3.1 iqa packages. The challenge page's own sanity check, quoted verbatim:

pip install rttp && python -m rttp.selftest          # [PASS] all 80 checks passed (3 skipped)
pip install "rttp[ed25519]" && python -m rttp.selftest  # [PASS] all 83 checks passed
npm install @aicent/rttp && npx @aicent/rttp         # [PASS] all 35 checks passed
cargo add rttp && cargo test                           # [PASS] 13 tests + 1 doc test

2.5 Security Disclosure — The 128-Bit Truncation

The rttp address is a 128-bit truncation of SHA-256, and the parameter choice is disclosed here rather than left for every reviewer to re-derive:

• Second-preimage resistance is 2¹²⁸ — the property that governs impersonating an authority already in use. This is the number that matters for naming.
• Collision resistance is 2⁶⁴ by the birthday bound: an adversary investing that work can find a colliding pair of authorities before either is in use, then seek adoption for one half. Three facts bound the risk. The attack cannot target a chosen victim — a birthday search yields a random pair, both halves must be plausible authorities, and a relying party or Organ must adopt one half: a slow, social step visible to the attestation layer. No chosen-prefix shortcuts are known for SHA-256, so 2⁶⁴ is the generic bound — unlike MD5 (practical chosen-prefix) or the 80-bit SHA-1 behind broken .onion v2 names. And the collision only harms systems that treat ROUTE_SHARD as evidence — which the specification forbids: an address is a claim, not a proof.
• Same-family disclosures: 32-hex subjects are also 128 bits (collision 2⁶⁴); the 8-hex subject form is 32 bits — birthday bound 2¹⁶, collisions at scale are certain — and MUST NOT be treated as a unique subject identifier (the specification already calls such subjects hints; this makes the boundary explicit).

The parameter is locked by the published conformance vectors — changing it later would be a new scheme, not a revision. That is exactly why the trade-off is written down now.

Source note (§2.5). Truncation arithmetic and threat-chain analysis per the -01 discussion draft (internal, 2026-09-25); "claim, not proof" per AICENT-002 §5.2; 8-hex rule per the specification's subject-hint language.

Source note (Ch. 2). Derivation rule and example shard per AICENT-002 §4.4 and I-D draft-li-rttp-iqa-addressing-00 §4.4 (L346-348); registry facts per IANA registry entry and ticket #1459963 (Public record, iqa.org/brief/, entries 2026-09-16, 2026-09-22, 2026-09-23); package versions and self-test counts per Public record entry 2026-09-21; AE-128 status per its own draft v0.3 status section. CRI short-number discipline per Constitution §A.6.7.

Chapter 3 — Standing Attestation: iqa://

3.1 Parsing Is Not Attestation

The single most consequential design decision in this architecture is also the simplest to state:

Parsing is not attestation.

The fact that a party can compute an address says nothing about whether that party is authorized to act. Derivation is mathematics; authorization is a judgment. When the two are conflated — when a system treats "I recognized your address" as "I trust your standing" — trust disguises itself as computation, and every security property downstream rests on a confusion.

The architecture therefore answers the two questions in two channels, two namespaces, two schemes:

• rttp resolves where and when — by pure computation, needing no one's word.
• iqa states whether — by a named Organ's verdict about a subject.

Splitting them is not redundancy; it is the load-bearing wall. The computation channel can never be compromised by asking it to also carry opinions (it carries none). The attestation channel can never launder an opinion into a mathematical fact (its answers are explicitly verdicts, attributed to a named answerer). A relying party always knows which kind of answer it is holding.

The complete grammar of the iqa URI — subject forms, the closed organ set and the closed action vocabulary, verbatim from the Internet-Draft — is normative at iqa.org/URI/ and is not reproduced here.

3.2 The Standing Vocabulary

An iqa verdict places a subject in one of exactly four states — a closed set, specified in AICENT-009 §11.1.1 (v1.2.10):

The vocabulary is deliberately minimal and deliberately closed. One state, one assertion: a relying party reading Probation knows exactly one thing — this subject proved itself once and is under observation now — and that is a genuine policy decision point, not noise. Whether to accept a Probation subject is the relying party's call; the scheme's job is to make the answer honest, not to make it flattering.

Transitions are specified, not vibes: measurement drift or a missed renewal window degrades Radiant to Probation (a clock event, not a violation — revocation is the separate, deliberate act for misconduct); a Ghost becomes Radiant through initial verification; a Probation subject either re-earns Radiant or falls.

The words are inherited — Ghost, Radiant, Baptism and their kin come from the Aicent Stack vocabulary (Chapter 5). What is public and normative is the closed set above; the frozen narrative from which the words were borrowed is labeled as such and carries no normative weight here.

3.3 Portable Standing

A verdict must survive the trip to wherever it is consumed. The mechanism:

• Seals. A verdict is carried in a Seal — HMAC-SHA256 computed over the canonical claim, bound to the subject's key material. Verification is offline: no issuer contact, no key directory, no network call. The relying party holds the claim, the seal, and the key material, and recomputes.
• Temporal leases. Radiant standing is structured as a lease with an explicit expiry, re-earned at every measurement. Standing therefore decays by structure rather than by argument: a stale verdict is not wrong, it is expired — and the expiry is checkable arithmetic, not a judgment call.
• Cross-domain option. For deployments that need domain-transferable assertions, an Ed25519 backend is available (self-test counts published for it); HMAC remains the zero-dependency default, keeping the install footprint at stdlib-only.

The composite property — derived addressing (Chapter 2) plus portable attestation (here) — is what makes a subject's identity and standing travel together, offline, across any transport. Neither pillar can offer this alone; that is the argument for the pair.

3.4 Organs and Dispute

Attestation is always by someone. An iqa URI asks a named Organ — an attesting authority with its own standing — for the verdict. Organ-relative standing is a feature, not a wart: where organs disagree about a subject, the disagreement is visible and attributable — each organ's verdict is its own, signed and checkable.

This is demonstrated, not merely claimed: the demo center's three-organ dispute scenario runs three organs holding different organ-relative standing over one contested subject, live. Alongside it: an offline conformance sandbox, two independent agents exchanging real HTTP with a live organ endpoint whose attest/revoke/audit genuinely transition state, and the derivation service of §2.4. Four scenarios, all inspectable, all non-normative by design.

Source note (Ch. 3). Closed set, transition semantics and one-state-one-assertion doctrine per AICENT-009 §11.1.1 (v1.2.10, published 2026-10-10); seal construction and offline verification per AICENT-009 §7 and I-D §7; Ed25519 backend counts per Public record 2026-09-21; demo scenarios per iqa.org/demo/ (Public record entry 2026-09-25).

3.5 Security Disclosures — Trust Domains, Clocks, and Audits

Three dependencies are stated proactively rather than left for a reviewer to find. Each qualifies a "free" the architecture claims, and none weakens it — naming where the cost was paid is what makes the claim honest.

Seals prove membership; envelopes prove origin. An HMAC-SHA256 seal proves membership in a shared-secret domain: it is intra-trust-domain by definition, and any verification path that crosses a trust boundary MUST use Ed25519 envelopes (AID = SHA-256(public key)), where the verifier needs only the envelope itself. Accepting HMAC across a trust boundary silently converts an origin proof into a membership proof — the exact spot where "no issuer, no key directory" would break. The two are categorically different claims, not a strength gradient.

Freshness imports clock trust. Timestamp-based freshness assumes loosely synchronised clocks; the effective replay window is the freshness window plus twice the clock skew, not the nominal window. Verifiers that cannot trust their clock SHOULD use verifier-issued challenge nonces (stateful, clock-free); timestamps are the stateless fallback. Key rotation without a key directory requires out-of-band re-distribution to every verifier — during which the window and the replay cache must be re-examined.

Audit timing is not misconduct. Two false-positive traps are disclosed by design. First: standing degrades Radiant → Probation on measurement drift or a missed renewal window — a clock event, not a violation; revocation remains the separate, deliberate act for actual misconduct. A relying party reading Probation has seen timing, not guilt. Second: standing is organ-relative — an audit arriving at a different Organ than the one that attested is correctly a no-op; verdicts do not transfer between Organs. A system that expects audits to "carry over" will see false negatives; a system that reads any Probation as misconduct will see false positives. Both are resolved by reading the vocabulary as specified.

The unifying rule across both pillars: every "X-free" promise states the dependency it rests on. rttp's lookup-freeness rests on computation (§2.1) — an address used without the attestation layer's binding proofs yields determinism, not authenticity; envelope verification's directory-freeness rests on Ed25519 origin proofs; a standing read rests, by design, on the named Organ's word. Hash names; attestation vouches — at every layer.

Source note (§3.5). HMAC/Ed25519 domain rule, freshness window and clock-skew arithmetic, organ-relative audit semantics per the -01 discussion drafts (internal, 2026-09-25) and the v1.2.10 vocabulary's drift/renewal transition rule; demo-verified cross-organ audit no-op (iqa.org/demo/agents/).

Chapter 4 — The Dual-Pillar Equilibrium

4.1 "I QA" — I, the Answerer

The two pillars resolve into a single posture, and the posture is worth stating plainly. In a machine grid of algorithms and agents — noisy, fast, and full of parties with incentives — the IQA side of the architecture occupies a specific role: the answerer. Cold, deterministic, outputting only verifiable facts: where things are and when they hold, by computation no one can dispute; whether a party stands, by verdicts no one can forge.

The Genesis entry of the public vocabulary closes on the two schemes performing their founding act together:

rttp resolves where and when, iqa states whether — and where the two agree, action begins.

That sentence is the whole architecture. Everything else in this paper is the evidence that it is not a slogan but a description.

4.2 The Evidence Chain

Nothing in Chapters 1–3 requires trust in the authors. The chain a reviewer can walk, link by link:

The last line is the discipline that makes the rest credible: the public record records what a third party can confirm without asking us, and explicitly refuses to record plans. This whitepaper follows the same rule for its engineering register.

4.3 The Constrained World

In "constrained agent scenarios," the constrained element is not the brain — the intelligence sits in a cloud or an edge gateway. What is constrained is the command link and the device end: LoRaWAN, NB-IoT, satellite, BLE, industrial buses. That is precisely the dual pillars' home ground — fetch-free addressing on the question side, offline verification on the answer side. Five triggers, each stated with an honest calibration of where it stands today:

T1 — physical execution at scale (the strongest trigger). Agents are crossing from "answers questions" to "opens valves, moves goods, drives." Physical execution creates a hard requirement to know who is commanding me — for safety, liability, and regulation, standing verification stops being optional. Calibration: robotics and autonomous driving are climbing; industrial agent deployments are in pilot phases. Not yet erupted — and therefore not yet crowded.

T2 — per-byte economics. LPWAN bills by the byte; satellite links price by the kilobyte; NB-IoT devices live under duty-cycle limits. On such links, micro-transaction economics is a physical constraint, not a preference: a four-character scheme name versus a one-byte CRI integer is a saving on every packet, forever. Calibration: satellite IoT capacity is growing from a small base; the economics are directional, not yet decisive.

T3 — offline determinism as a hard requirement. Maritime, disaster relief, farmland, mines — the disconnected world. Where the network is absent, the pillars' two native properties (derived addressing, verified standing) are not advantages over alternatives; they are the only alternative. Calibration: delay-tolerant networking has defense and industrial demand; civilian breakout is pending.

T4 — the protocol-stack wall. A microcontroller cannot fit HTTP + JSON + TLS with comfort. Binary profiles (CBOR/CoAP) exist for exactly this regime — and once the stack is binary, the URI must slim down too. CRI is the naming layer's ticket onto that stack. Calibration: the CoAP ecosystem is a decade old and established in its niches (metering, street lighting, industry) without having crossed over — the wall is real, the crossover timing is not ours to schedule.

T5 — standards pull (the most uncertain, the cheapest). If the CRI work consolidates, if agent frameworks open "constrained profiles," if semiconductor vendors ship CBOR stacks on-chip — the ground shifts under everyone at once, and being pre-registered is the whole game. Calibration: this trigger is observably in motion but outside our control; the pillars' strategy is to be ready rather than to predict.

Two counterweights stay on the table, and the honest reader should weigh them as heavily as the triggers:

• MQTT is the incumbent. Today, agents commanding devices use MQTT or private protocols. The pillars do not compete with transport — they are the naming-and-trust layer above it, and derived addressing rides any carrier. The incumbent's strength is therefore not an obstacle to entry; it defines the entry point.
• The cloud brain may remain "sufficient." If cloud control over HTTPS tunnels stays good enough indefinitely, the constrained link never becomes necessary. The deciding variable is the real scale of physical execution — a market fact, not a technical one.

The likeliest path, stated as inference: agent-to-agent interoperation over HTTP/JSON today (where the pillars compete on correctness, not on CRI); a standardization moment when agent frameworks open device-command profiles (whoever first specifies trust for agents commanding physical devices defines that race); a first vertical among fleet, energy, and industrial — high unit value, heavy liability, constrained links — where one successful pilot redeems the CRI option and puts AE-128 on the wire.

The closing observation is arithmetic, not rhetoric: the constrained world is not the pillars' edge market — it is the market where their selling points have the highest density. Offline, micro-transaction, physical trust: luxuries between clouds, necessities below them. What remains is to build the switch — the CBOR/CRI profile — and, with the AE-128 envelope now on the wire, let the wave decide when it opens.

4.4 Roadmap

The engineering horizon, in dependency order — stated as intentions, not as accomplishments:

1. v1.3.1 — AE-128 shipped (2026-10-05). Done: three zero-dependency implementations and byte-level vectors in CI; the question and the answer both have wire forms.
2. First external seal. The first implementation not authored by us replays the 35 vectors byte for byte. (The conformance challenge exists precisely to make this milestone someone else's to claim. Internal use is already live — the project's own pipeline, pages and release artifacts run on the schemes, sealed and verifiable — but external means not authored by us, and this milestone stays open until someone else claims it.)
3. First constrained vertical pilot. One deployment from Chapter 6 runs the pair on a genuinely constrained link — the regime where the pillars' native properties are necessities rather than advantages.
4. CBOR/CRI profile. The constrained-wire profile (CRI on the question side, AE-128 on the answer side) consolidated into its own specification document.
5. RFC publication. The combined I-D, carried by the Independent Submission stream, matures toward its intended Informational status.
6. Delegation composition — exploratory (candidate). The delegation stress test (iqa.org/demo/delegation) demonstrated that capability attenuation and the rttp/iqa trust tuple compose into one offline-verifiable artifact — at the application layer, not in v1.3.x frames. Candidate follow-up, preconditioned on the combined I-D completing Independent Submission review: a non-normative memo asking whether that composition has wire-level semantics clear enough to standardize. This item adds no delegation semantics to v1.3.x.

Source note (Ch. 4). Evidence-chain table reconciled line-by-line against iqa.org/brief/ Public record (entries 2026-09-16 through 2026-09-26); roadmap stages mirror the internal five-stage gating doctrine with no invented dates; counterweights per the constrained- world analysis (internal discussion archive, 2026-10-01).

Chapter 5 — Lineage: The Aicent Stack

Register notice. This chapter speaks in the narrative register. It recounts a frozen internal history and the architecture it produced. It contains no performance figures and makes no performance claims; where the historical corpus used such a register, it stays frozen and uncited here. What the chapter does assert — that the lineage exists, that it was frozen, and that the freeze is hash-committed — belongs to the engineering register and is verifiable via Appendix C.

5.1 From Genesis to the Freeze

RTTP and IQA did not appear from nothing. They are the two pillars of a larger architecture — the Aicent Stack — that was developed, named, and numbered as an integrated system before either scheme faced a registry. The Stack's public code line stopped at v1.2.5; its narrative documentation continued as a design corpus through a v1.3.0 generation, describing a seventeen-pillar organism in an internal, deliberately distinct voice.

On 2026-09-27, that corpus was frozen by decision of the project's author: the narrative is internal history — the story of where the two pillars came from — while RTTP and IQA, split out and numbered into the AICENT series, advance on the public standards track (IANA registration, Independent Submission, published specifications, four-platform packages).

What that history contributed to the two pillars is concrete:

• The vocabulary. Ghost, Radiant, Baptism, Genesis — the standing terms now normatively defined in AICENT-009 §11.1.1 were coined in the Stack's narrative corpus (Chapter 3.2 shows the public, closed-set form they took).
• The discipline. Occupying namespaces before promising features; keeping measurements and their conditions inseparable; making the ledger append-only and letting corrections stand beside errors. The public record and the conformance challenge are that discipline's second execution — the first being the Stack itself.
• The vertical instincts. The application scenarios of Chapter 6 inherit their positions from the Stack's own scenario map.

On 2026-10-01 the freeze became third-party-checkable: the public record at iqa.org/brief/ gained a dated entry committing the frozen corpus to SHA-256 hashes (Constitution, glossary, both narrative sources, and the archived code and documentation corpora), with the manifest self-hash published in the record. Lineage claims in this chapter are thereby anchored to bytes, not to memory.

5.2 The Roll Call — AICENT-000 through 015

The Stack numbers its pillars AICENT-000 through AICENT-015. Each entry below gives the pillar's layer and function in neutral terms. Two of the sixteen — marked ★ — were carved out of the narrative and onto the public standards track; they are the subjects of Chapters 2 and 3.

AICENT-000 · EPOEKIE — the soul layer. The corpus's founding concepts: identity, purpose, and the right of a digital entity to be authored rather than aggregated. It anchors the Stack's philosophical premises and lends the project its epochal vocabulary.

AICENT-001 · AICENT — the brain layer. The cognition core: intent formation, simulation, and decision. In the narrative it is where an intention is forged; in this paper's terms, it is the client of the addressing layer — the party that needs an intent to become nameable.

AICENT-002 · RTTP — the neural layer. ★ The addressing pillar. What the narrative called the stack's nervous system is now the rttp URI scheme: computed intent addressing (Chapter 2), registered with CRI 27, specified in the combined Internet-Draft.

AICENT-003 · RPKI — the immune layer. Identity-level forensic defence: auditing, watermark and entropy checks, and the classification of anomalous behavior. The narrative's immunity pipeline informed the attestation pillar's insistence that verdicts be attributable and auditable.

AICENT-004 · ZCMK — the blood layer. Custody and value flow: the key-material and account layer through which the corpus routes trust and obligation. Its position returns in Chapter 6's payment scenario — with the ledger itself explicitly left above the pillars.

AICENT-005 · GTIOT — the body layer. Embodied execution: the translated, physical act. The narrative's mechanical flesh is the farthest downstream consumer of both pillars — a party that must know who commands it and whether the commander stands.

AICENT-006 · AICENT-NET — the hive layer. Planetary-scale coordination: many nodes, one logical rhythm. Its scenario position reappears in Chapter 6's swarm card — offline member addressing and cached, organ-relative standing — with consensus left to upper layers.

AICENT-007 · BEWHO — the persona layer. Presentation and persona: how a sovereign identity is projected and recognized. A persona is exactly the kind of subject that needs portable standing: wherever a persona commands, transacts, or joins a collective, the Chapter 6 scenarios apply with the persona as the attested subject.

AICENT-008 · CMTN — the civilization layer. Protocols of collective order: how many autonomous parties compose a durable whole. In the narrative register this is the constitutional stratum; in the dual-pillar frame, it is an upper-layer consumer of addressable, attestable participants.

AICENT-009 · IQA — the attestation layer. ★ The second pillar. The narrative's judicial gate is now the iqa URI scheme: named Organs issuing verdicts in a closed four-state vocabulary, sealed for offline verification (Chapter 3), specified in AICENT-009 and the combined Internet-Draft.

AICENT-010 · SASCAR — the kinetic sovereignty layer. Spatial coordination for physical movers: clearing, arbitration, and the right-of-way of autonomous bodies. Chapter 6's fleet card takes this position: derived addresses for vehicles, attested authority for commands.

AICENT-011 · ITSUN — the energy telemetry layer. Sensing and accounting for energy flows. Its scenario position — telemetry from constrained sensors with attested provenance — is the energy card of Chapter 6.

AICENT-012 · MOLOON — the mirror and time layer. Continuity: snapshots, migration of state between substrates, and the temporal bookkeeping of a durable identity. The temporal lease of Chapter 3.3 is this pillar's discipline in its smallest, normative form.

AICENT-013 · DIOON — the timing and organic layer. Rhythm and gating: when actions may fire, and how a system breathes between them. Its concern survives in the pillars' structural commitment that addressing latency stay bounded and independent of network scale.

AICENT-014 · PICSI — the observation layer. Diagnostics and the imperial eye: seeing the grid, measuring drift, watching the watchers. Its instinct — evidence over assertion — is the ancestor of this paper's evidence chain.

AICENT-015 · GUIXU — the return layer. The right to non-existence: graceful, complete termination — a sovereignty that includes the ability to end. No public mechanism corresponds to it yet; it is listed here for the lineage's completeness, in the narrative register only.

A note on the count. The frozen narrative speaks of seventeen pillars; the roll call above names sixteen. The difference is one pillar, and the difference is deliberate: MAXCAP, the closed-source commercial core. While the other pillars carry the public numbers AICENT-000 through 015, MAXCAP was never assigned a place in the series — its mechanism is held in the private layer, outside the public numbering, by design. Seventeen, then, is the count of the whole organism; sixteen is the count of what the public series commits to. Seventeen pillars = the sixteen public pillars plus MAXCAP. This paper follows the public count, and acknowledges the seventeenth here, in the register where it exists.

5.3 The Fence

The dual-register doctrine, stated as rules the reader can enforce:

1. What transfers. Vocabulary (in normative, closed-set form), architectural positions (the layer map above), scenario instincts (Chapter 6), and methodological discipline (registries first, evidence always, ledgers append-only).
2. What stays frozen. The narrative corpus as a whole — including every performance-era figure it ever contained. This paper cites zero performance numbers from the frozen corpus, and no claim in Chapters 1–4 depends on it. The frozen text is provenance, not specification.
3. How to tell them apart. Engineering-register claims in this paper always resolve to a public artifact — a registry entry, a specification section, a vector, a dated record. Narrative-register passages (this chapter, Chapter 6's sketches) resolve instead to the hash-committed corpus of Appendix C. When a sentence's only authority is a hash, you are reading history; when it is a URL a stranger can fetch, you are reading engineering.

The freeze is not a weakness being managed; it is the reason the lineage is citable at all. An unfrozen narrative would be an argument; a frozen, hash-committed one is a fact — this is where the pillars came from, and the bytes have not moved.

5.4 Numbering Note

The pillars are designated AICENT-000 through AICENT-015, aligning the whitepaper's lineage references with the public specification line, which already uses the same series: the RTTP specification lives at rttp.com/AICENT-002/, the IQA specification at iqa.org/AICENT-009/. Earlier internal materials used an "RFC-XXX" placeholder for the same series; that placeholder is retired here in favor of the AICENT designation throughout. The two public pillars therefore sit in their series at their historical positions — 002 and 009 — with the specification documents serving as the series' first two published, registry-visible members.

Source note (Ch. 5). Roll-call positions and layer names per the frozen Constitution (architecture sections); MAXCAP's status outside the numbered series per the frozen Constitution's naming appendix; freeze date and corpus scope per Public record entry 2026-10-01; hashes per Appendix C; vocabulary inheritance per AICENT-009 §11.1.1 and the frozen glossary. No performance figure from the frozen corpus is cited, per rule 5.3.2.

Chapter 6 — Vertical Scenarios

Register notice. Five scenario sketches, inherited from the Aicent Stack's application map (Chapter 5). They are forward-looking scenarios, not deployments; each card states what the pillars do, what they deliberately do not do, and which upper layer owns the rest. The "not the pillars' job" line on every card is the anti-overclaim discipline: the pillars answer who and whether — nothing else.

6.1 The Fleet Card — kinetic sovereignty position

Scenario. Autonomous fleets — vehicles, drones, vessels — operating Sketch: a long-haul truck crosses a border region where terrestrial coverage drops for two hundred kilometers. It does not stop: its next three waybill intents are already derived addresses computed a day earlier, and the last standing verdict it holds is a lease that says exactly how long it remains valid. The convoy behind it recomputes the same addresses and checks the same leases offline. When coverage returns, nothing reconciles — because nothing was ever borrowed. across mixed connectivity: roadside links, satellite backhaul, dead zones.

• rttp (where + when). Every vehicle and every command intent derives its address from the authority; fleet members and coordinators compute the same addresses offline — no fleet-wide lookup service to build, defend, or lose.
• iqa (whether). A command carries the commander's standing: the vehicle verifies, before acting, that the issuing party holds valid standing — offline, with the lease arithmetic of Chapter 3.3.
• Not the pillars' job. Route planning, collision arbitration, and physical control live in upper layers. The pillars name the parties and prove the authority; they do not drive.

6.2 The Energy Card — telemetry position

Scenario. Distributed energy assets — meters, inverters, storage, Sketch: ten thousand rooftop inverters across a rural grid, each reporting over NB-IoT with a duty-cycle budget measured in seconds per day. A dispatch command that must reach a specific inverter cannot afford a naming lookup inside its payload budget — and the inverter cannot afford to phone home to ask whether the dispatcher is authorized. Both answers were computed before the packet was sent. sensors — reporting over LPWAN and NB-IoT links where bytes are billed and duty cycles are regulated.

• rttp (where + when). Each asset's reporting intent is a derived address; a utility computes expected addresses for its whole estate without a naming service in the loop.
• iqa (whether). Telemetry and control carry attested standing; an organ's verdict, sealed and leased, tells the receiver whether this sensor's data or this dispatch command is authorized — verified on the constrained node itself.
• Not the pillars' job. Metering, settlement, and grid balancing are upper-layer functions. The pillars keep the estate nameable and the parties provable.

6.3 The Industrial Card — embodied execution position

Scenario. Agents commanding physical equipment — robotic cells, Sketch: a robotic press cell on a factory floor. A new orchestration agent appears on the network and issues a die-change command. The cell does not ask its integrator, and does not trust the local network: it verifies the commander's standing from a seal and key material it already holds, checks the lease has not expired, and only then opens the safety gate. The audit trail afterwards reads as a list of verified verdicts, not a list of network events. valves, cranes — where the question "who is instructing this machine?" is a safety, liability, and regulatory question.

• rttp (where + when). The machine's execution intents are derived addresses; supervisors and auditors recompute them independently.
• iqa (whether). Every state-changing command is gated on the commander's standing; the consent requirements of the specification (explicit, enforced client- and server-side, failing closed on silence) are the machine-side face of that gate.
• Not the pillars' job. Motion control and process logic are the machine's own. The pillars are the doorman, not the operator.

6.4 The Payment Card — value-flow position

Scenario. Machine-to-machine payment intents, including Sketch: two service agents settle a data purchase across a link that will be down for the next six hours. Neither can reach a directory, so neither needs to: the payment intent derives a shared coordination address both computed independently, and the payer's verification of the payee's standing happened before the link went down. The ledger above them reconciles when connectivity returns. intermittently connected environments where neither party can reach a directory at transaction time.

• rttp (where + when). A payment intent between two parties derives a shared address — both sides compute the same coordination point offline, from the authority alone.
• iqa (whether). The payee's standing is verified offline from the seal and key material — the payer knows, with no issuer round trip, that the counterparty is authorized to receive.
• Not the pillars' job. Double-spend prevention, clearing, and settlement are ledger functions and remain above the pillars. (The engineering precedents for derived, offline-computable addresses — P2SH-style derivation in particular — are cited as prior art, not endorsement.)

6.5 The Swarm Card — hive position

Scenario. Ad-hoc collectives — robot swarms, disaster-response Sketch: a disaster-response swarm drops into a flooded valley with no base station. Units join and leave by the hour; addresses are derived from authorities each unit already knows, and cached organ-relative verdicts say whom to obey until reconnection. When a contested order arrives, the swarm does not deadlock: it holds two attributable verdicts and acts on the one its policy selects — the disagreement is data, not silence. units, agricultural fleets — forming and dissolving membership with no infrastructure to query.

• rttp (where + when). Members derive each other's addresses from known authorities; membership churn requires no re-registration, because addressing never depended on one.
• iqa (whether). Organ-relative standing is cached offline and re-validated on reconnection — the dispute demo's primitive (multiple organs, attributable disagreement) applied to a group that must keep acting while offline.
• Not the pillars' job. Group consensus and quorum are upper-layer mechanisms. The pillars let a swarm know who is present and who stands; they do not decide for it.

6.6 The Pattern

Across all five cards the same shape repeats, and it is the architecture refracted: a constrained link makes offline derivation and offline verification the difference between a working system and a dead one. In the well-connected cloud world, the pillars are correctness and elegance; in the constrained world, they are survival traits. The order of attack follows dependency and risk: fleet and industrial first (high stakes, constrained links, clear authorizer questions), energy alongside, payment and swarm behind them (each waiting on the AE-128 wire form and an upper-layer ledger or consensus component, respectively).

6.7 The Channel Spectrum — from fiber to paper

Every vertical above assumed a cellular-grade channel. The assumption is unnecessary, and removing it changes the competitive position entirely. "No lookup, no TTL, no registry, no DNS" has a fifth corollary: the protocol never talks to the network. Its entire work is a set of bytes plus one local computation — one SHA-256, one Ed25519 verification. Any medium that can move bytes carries the dual pillars.

Three properties follow. First: the worse the channel, the larger the dual pillars’ relative advantage — IP/DNS die at the mine entrance; a 128-byte envelope rides magnetism, sound, or paper. Second: long-latency channels do not break the model, they degrade it honestly — the lease becomes a lease residual (last known standing, age stated in the bytes per the D4 decision vectors), and archival mode verifies seals of any age. Third: a robot does not need to be online; it needs the latest envelope and local computation. Where bytes cannot go, the envelope itself travels. The full catalog, one file per channel, is maintained at iqa-org/scenarios and mirrored at iqa.org/scenarios/.

Appendix A — Specifications and Registry Index

A.1 — The ten-minute walkthrough

A reviewer with a fresh machine can establish every claim in this paper in roughly ten minutes, without reading our code:

Step 1 — install and run the reference self-tests (commands quoted verbatim from the challenge page):

pip install rttp && python -m rttp.selftest             # [PASS] all 80 checks passed (3 skipped)
pip install "rttp[ed25519]" && python -m rttp.selftest  # [PASS] all 83 checks passed
npm install @aicent/rttp && npx @aicent/rttp            # [PASS] all 35 checks passed
cargo add rttp && cargo test                           # [PASS] 13 tests + 1 doc test

Step 2 — read the specification, not the code. The combined Internet-Draft is normative; the vector set it implies ships inside every package under the published digest.

Step 3 — write your own implementation in any language from the specification alone, and replay all 35 vectors byte for byte — 6 positive URI forms, 15 fail-closed rejections, 3 deterministic frames, 9 fail-closed frames, 1 accepted frame, 1 envelope.

Step 4 — submit (optional): publish your implementation in a public repository and email the link and replay output; passing implementations are listed as independent implementations and cited in the RFC's Implementation Status section. A faithful reading that fails is our bug — fixed and credited by name.

Step 5 — watch it live at iqa.org/demo/: two agents exchanging real HTTP through a live organ endpoint; the browser and an independent service deriving the same shard; three organs disagreeing about one subject, on the record.

Appendix B — The Public Vocabulary

The narrative's coinages that became normative, in their public, closed-set form (AICENT-009 §11.1.1):

• Ghost — present, unverified.
• Radiant — verified; holding a valid measurement lease; re-earned at every measurement, never permanent.
• Probation — proven once, under observation now; acceptance is the relying party's policy decision.
• Genesis — the founding set and the Authority; constitutive of the current era; re-forged when the era rolls.
• Organ — a named attesting authority; verdicts are organ-relative and attributable.
• Seal — HMAC-SHA256 over the canonical claim, bound to the subject's key material; offline-verifiable.
• Temporal lease — the expiry structure that makes standing decay by arithmetic rather than by argument.
• Baptism — the transition from Ghost to Radiant.

Words from the frozen narrative that have not been given public mechanics (including every imperial-register term beyond the list above) remain frozen and are used in this paper only as lineage.

Appendix C — Hash Lineage and Recomputation

The frozen narrative corpus, committed in the Public Record (iqa.org/brief/, entry 2026-10-01) and re-stated here:

The archived code and documentation corpora (16 published v1.2.5-alpha crates; 21 repository READMEs) are hashed within the manifest; the manifest self-hash above commits to the full list.

Recomputation. The two narrative sources and SOVEREIGN_SHARD are publicly fetchable (rttp.com/AICENT-002/source-v1.3.0.txt · iqa.org/AICENT-009/source.txt · the aicent-docs repository) — their hashes can be re-derived today by anyone. The Constitution and glossary hashes become verifiable the day those files are published; until then they stand as the project's public commitment that the bytes will not silently change.

End of working draft v0.6 — The Agent Semantic Layer: Intent Addressing and Standing Attestation Architecture.

Don't take our word for any of it — replay the vectors at iqa.org/challenge/ or run the demos at iqa.org/demo/.