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 two different kinds of questions — where 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 scheme number 27) with iqa in registration; 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
3. Standing Attestation: iqa:// — parsing is not attestation · the standing vocabulary · portable standing · organs and dispute
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.)

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 scheme number 27 (allocated in the expert-review range), completed 2026-09-22 with designated-expert approval. The companion iqa request (IANA ticket #1459963) has passed name review; its CRI number is in expert review at the time of writing. 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) — on the roadmap, stated as such. To let the answer side enjoy the same economy, a fixed 128-byte envelope is under specification (working draft v0.2; targeted for the v1.3.1 cycle). 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     16   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 and nonce are authenticated too, so a rewrite of the named answerer 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 appears in this paper as a roadmap artifact with a published draft layout and computed vectors — not as a shipped mechanism. When it ships, the question and the answer will each have a wire form:

        ┌──────────────┐            ┌──────────────┐
        │  rttp side   │            │   iqa side   │
        │ pulse frame  │            │   AE-128     │
        │ shard @0x36  │            │ shard @0x10  │
        └──────┬───────┘            └──────┬───────┘
               │      SAME 16 OCTETS       │
               └────────────┬──────────────┘
                            ▼
              one datagram carries WHERE 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 —

| Tier | Contents | |---|---| | 1 — the URI gauntlet (21 vectors) | 6 positive forms and 15 fail-closed rejections: if a parser accepts what the spec says to reject, it fails exactly where the spec says it must | | 2 — the frame and the envelope (14 vectors) | 3 deterministic frames, 9 fail-closed frames, 1 accepted frame, 1 envelope (the envelope check exercises the Ed25519 backend; everything else is zero-dependency) |

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 — PyPI rttp / iqa-org 1.2.8, npm @aicent/rttp / @aicent/iqa 1.2.8, crates.io rttp / iqa-org 1.2.8-alpha — with GitHub CI re-asserting the published self-test counts on every push. 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@1.2.8-alpha && cargo test             # [PASS] 37 checks (1 skipped)

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.2 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 answers where — by pure computation, needing no one's word.
• iqa answers 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.

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.9):

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.9, published 2026-09-26); 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).

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, 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, 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 the AE-128 envelope — and 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 ships. The 128-byte attestation envelope (§2.3) lands with three zero-dependency implementations and byte-level vectors in CI; the question and the answer both get 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.)
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.

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.

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); 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). 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). 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). 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). 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). 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).

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@1.2.8-alpha && cargo test                # [PASS] 37 checks (1 skipped)

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.1 — 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/.