iqa — V1.3.1 release reading

iqa://subject.organ.root/action
The question and the answer as 128-byte frames rttp:// PulseHeader128 and the iqa:// AE-128 envelope are both fixed 128-byte frames sharing the same 16-byte intent shard. rttp:// · PulseHeader128 — the question (WHERE + WHEN) · VERSION_ID 130 128 B fixed header · timestamp · seq · TTL AID origin (32 B) SPEC_REV + ACTION 0 0x36=54 0x66=102 128 Same 16 bytes · rttp ROUTE_SHARD = iqa intent_shard offset 0x36 ↔ 16 iqa:// · AE-128 envelope — the answer (WHETHER) · HMAC-SHA256 full-frame 128 B fixed IQAE remaining fields (whole frame MAC-authenticated) 0 16 80 128 offset 80 · standing closed 4-state set · O(1) read question frame answer frame shared shard (16 B) zero / padding
The two pillars on the wire: rttp resolves WHERE and WHEN (a 128-byte PulseHeader128 carrying timestamp, sequence and TTL), iqa states WHETHER (a 128-byte AE-128 envelope). Hover any field for what it does; click to pin the note. The same 16-byte intent shard — one derivation of the authority, carried at offset 0x36 in the question and at offset 16 in the answer — is the seam where question and answer lock together — where the two agree, action begins.
Engineering rationale — why two fixed 128-byte frames (click to expand)

I. Symmetric fixed-length frames — the full optimum for constrained devices.

1 · Static memory, zero heap allocation. Ask 128, answer 128 — a node allocates two fixed buffers at compile time; the hot path has no variable-length parsing, no TLV walking, no malloc. On MCU-class devices "no heap" directly means no fragmentation, no leak surface, predictable real-time behavior. This is the engineering delivery of the zero-parser claim: verification needs only the SHA-256/HMAC primitives plus fixed-offset reads.

2 · One review technique, two carriers. Both frames are fixed-layout, so reading them uses the same trivial method — constant offsets and hash primitives — and each reader can be audited in isolation. The carriers remain independent codecs (the specification requires that they do not parse each other); what is shared is the discipline, and that is what keeps every audit small.

3 · Fixed length → constant-time-friendly. The MAC comparison runs over a fixed layout with no variable-length loops, shrinking the side-channel surface; fields are O(1) reads — standing at offset 80 is an array index, not a "parse then extract". The validator is also total: every 128-byte input is either accepted or rejected whole, never partially parsed, and the rule set is small enough to reason about exhaustively, rule by rule.

4 · 128 is backed by hard constraints. A power of two (aligned allocation) and exactly two cache lines; above all, one datagram, no fragmentation: 128 bytes plus roughly 60 bytes of IPv6/UDP/CoAP header overhead fits comfortably inside the 1280-byte minimum MTU — fragmentation means reassembly buffers, reassembly means heap, and heap is a death sentence on constrained nodes. The upgrade runway is proven, not promised: the pulse frame tail (0x66–0x7F) went from zero bytes to the v1.2.6 extension block without changing the total length, and AE-128 reserves its own zero bytes (reserved + extension) for the same future.

II. The shared shard — the cryptographic handshake of the Q&A.

The amber link on the map is the most valuable stroke: the intent_shard at 0x36 in the question and at 16 in the answer are the same 16 bytes. Three engineering layers:

1 · One round trip. Addressing (WHERE + WHEN) and standing (WHETHER) ride the same exchange: one question, one answer — one round trip does what used to take two. On duty-cycle-powered LPWAN links, round trips are the dearest resource.

2 · The answer is bound to its subject. The MAC covers the intent_shard, so an answer cannot be re-targeted: swap in another subject’s shard and the bytes no longer authenticate — fail-closed. Freshness is carried separately, by the lease and the organ’s per-verdict nonce.

3 · From document pairing to byte pairing. "One datagram carries WHERE, WHEN and WHETHER" is no longer prose: two 128-byte frames sharing one constant is the physical implementation.

III. What is saved, against current practice.

CarrierSizeParser required
JSON envelope (the original AE route)hundreds of bytesJSON parser + field walking
CBOR encodingcompactCBOR decoder (TLV logic)
AE-128 / PulseHeader128128 bytes each, cappednone — fixed offsets + hash primitives only

Scope of this reading. This is the current-release (V1.3.1) reading of AICENT-009. The scheme itself is unchanged against V1.2.8 and V1.2.6 — same syntax, same envelope layout, same derivation, same closed sets. What V1.3.1 adds is the answer-side wire form: the AE-128 attestation envelope, shipped in three zero-dependency implementations, with the full release now published at version 1.3.1 across all four distribution channels.

Distribution (all 1.3.1). PyPI iqa-org 1.3.1 · npm @aicent/iqa 1.3.1 · crates.io iqa-org 1.3.1 (the first formal, non-pre-release publication of the crate) · GitHub Aicent-Stack/iqa-org. Asserted self-test counts: Python 108 passed (3 skipped) default, 111 with the Ed25519 backend; Node 32 (conformance replay); Rust 18 tests + 2 doc tests default, 20 + 2 with the backend. GitHub CI re-asserts every published artifact on every push: 15 jobs, all green.

AE-128 — the answer carrier. The rttp pulse frame carries the question; AE-128 carries the verdict. A fixed 128-byte frame, transport-independent, zero-parser verification: a receiver needs only SHA-256/HMAC-SHA256 and fixed offsets — no CBOR decoder, no TLV walker. Layout (all integers big-endian, offsets zero-based):

Offset  Len  Field          Description
  0      4   magic          'IQAE' (IQA Envelope — scheme-anchored)
  4      1   version        0x01
  5      1   algorithm      0x01 = HMAC-SHA256
  6      2   flags          unassigned in version 1 (send 0x0000)
  8      8   lease_expiry   u64 BE Unix seconds — verdict valid until
16     16   intent_shard   ROUTE_SHARD of the subject (I-D §4.4)
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       0x00 Ghost · 0x01 Probation ·
                            0x02 Radiant · 0x03 Genesis (§11.1.1)
81     15   reserved       MUST be all zeros
96     32   extension      MUST be all zeros in version 1
──────────────────────────────────────────────────────────────────
128 octets exactly — one frame, one datagram, under any MTU

Canonical rule and what it buys. The attestation is HMAC-SHA256 over the entire frame with the attestation field itself zeroed — so the organ tag, the nonce, the lease and the standing byte are all authenticated: a rewrite of the named answerer, an expired-lease re-stamp, or a flip of the verdict state (Radiant to Genesis) cannot survive verification. Verification repeats the computation and compares constant-time.

Vectors, born with the format. The published vector AE128-VECTOR-1 reproduces byte for byte from the documented parameters alone (authority f3b2a1c4.pillar.example, ROUTE_SHARD 557c8154d3780cb78cc5fa1bd72b331c, attestation 4bd14b6a…84596a). The shipped file ae128-vectors-v1.json carries 1 positive, 11 fail-closed and 7 tampered frames — one sha256 across the Python, JavaScript and Rust mirrors — and a 200,000-case deterministic harness shows that no single-byte mutation of a frame survives verification. The format is specified in companion draft v0.3; it creates no IANA/ISE obligations.

Reading order. The normative scheme text remains the V1.2.8 reading (V1.2.6 syntax, frozen) plus the §11.1.1 standing vocabulary (v1.2.10). This tab is the release reading: what V1.3.1 adds on top. The V1.2.6 tab keeps the original birth reading; the ACI tab keeps the legacy narrative.