Runtime reference
A narrative, per-concept account of how the base protocol runs, deep enough to build an interoperable implementation.
Audience: developers · Read route: rebuild · Reflects specification v0.1
This is the runtime reference: a narrative, per-concept account of how the base protocol runs, aimed at a developer who wants to build an interoperable implementation. It is the deepest layer of the documentation. The conceptual overview in How it works sketches the shape; this reference gives the mechanism, with a diagram or a worked example for every concept.
The reference explains how the runtime works and how to build each part. The rules an implementation MUST satisfy live in the base protocol specification, and the conformance section there names the test-vector suites that pin the exact bytes. Each page below points to the specification section that carries its rules. Where this reference touches a sub-topic that is still under technical review, it marks that sub-topic as provisional in place and collects every such item in the Provisional items and exclusions register below. Nothing is silently dropped.
Every page on this reference reflects specification version 0.1.
How the runtime fits together
One party runs one runtime. Inside it, three replaceable roles sit around locally owned state: a writer encodes and signs and submits, a reader admits recorded actions and replays them, and a recorder persists state and checks that a replay reproduces it. The only piece any party shares is the public audit layer, because that is the one piece no party can rewrite. An overlay routing fabric carries records between parties on their way to the audit layer.
The concepts, in reading order
| Page | Concept | The specification section behind it |
|---|---|---|
| Runtime and replay | Machines read a shared, ordered stream and rebuild their own state; deterministic replay; the drift halt; schema evolution by method version. | Section 3.5 |
| Data integrity and verification | State is reproducible from the log and every change is detectable; the three properties that follow from deterministic replay. | Section 3.5 |
| The envelope and field-level encryption | The versioned typed-tier record, deterministic encoding, per-field encryption, selective disclosure, and the placement descriptor. | Sections 3.1, 3.3 |
| Keys and derivation | The five-level, dual-curve hierarchy, derive-not-store, composable custody, and rotation by epoch. | Section 3.3 |
| Anchoring and the audit log | Chained, ordered, tamper-evident recording, independently verifiable proofs, and cross-domain references that carry their own proof. | Section 3.4 |
| Identity and delegation | The four-link identity chain, scoped and revocable mandates, and local verification with no network on the hot path. | Section 3.6 |
| Addressing and discovery | The overlay as a routing fabric over the open overlay standards, and the two meanings of "overlay". | Section 3.2 |
| Topologies | Full, query-replica, ingest-only, and observer, each an adapter swap over one code path. | Section 5 |
The terms used across these pages (party, record, recorded action, envelope, field, placement, the public audit layer, anchor, anchor reference, proof, mandate, delegation, epoch, register, claim, port contract) are defined once, in the specification glossary (Section 2.3). This reference uses them with exactly those meanings so that the reference and the specification never drift apart.
Provisional items and exclusions
The rules stay in the specification; this register just gathers, in one place, every sub-topic still under technical review so nothing is hidden. It mirrors the four provisional items the specification carries, each marked in place on the page it belongs to and collected here for the whole reference. Each points back to the specification, Section 9; this register does not redefine them.
| Item | Topic | Where it appears in this reference | Points back to |
|---|---|---|---|
| PROV-1 | Settlement-layer naming and anchoring mechanics | Anchoring and the audit log | Specification Section 3.4, Section 9 PROV-1 |
| PROV-2 | Forward-secrecy trade-off | Keys and derivation | Specification Section 3.3, Section 9 PROV-2 |
| PROV-3 | Placement-channel ownership, and consortium membership and instance ownership | The envelope and field-level encryption and Addressing and discovery | Specification Sections 3.2 and 3.3, Section 9 PROV-3 |
| PROV-4 | Data-protection erasable-mandate pattern | Identity and delegation | Specification Section 3.6, Section 9 PROV-4 |
| Exclusion | Operator-infrastructure detail (provisioning, hosting, key-management-service or hardware-module set-up, funding, custody topology, resource envelopes, and operator runbooks) | Topologies | Specification Section 5 |
What this reference excludes outright. Content from the internal threat model and from the internal privacy analysis is excluded from this reference, not deferred: it does not appear here in any form. The test-vector suites are named only; no vector value is embedded anywhere in these pages. The settlement layer that the public audit layer resolves to is named only "the public audit layer" throughout.