Specifications

This is the formal layer of the registry stack documentation. Where the tutorials and explanation pages teach and orient, these documents define: each one is an independently identified, versioned specification written so a third party can implement, audit, or govern against it.

The documentation has three layers, and each page belongs to exactly one:

• Practical docs (Get started, Tutorials, Explanation, Reference) are task-oriented and developer-facing. Read them to learn the system.
• Formal docs (these pages) are system-facing, versioned, and evidence-backed. Read them to build an independent implementation, to audit a claim, or to govern a deployment.
• Internal evidence (release records, security review notes, deployment specifics, working plans): formal docs are distilled from these internal engineering records, which are not published.

A specification is not a more formal copy of a guide. It is a contract. When a practical page and a current, normative specification disagree, the specification governs. A specification that is still draft does not yet carry that authority; it states the intended contract while it is reviewed.

Register

The register lists every specification, its role, how true it is against shipped code, and where it sits in its lifecycle. It is generated from each document’s own frontmatter, so it cannot drift from the documents it lists.

ID	Document	Category	Evidence	Status
RS-ARC-G	RS-ARC-G: Registry family architectureThe authoritative architecture specification for the registry stack, defining the two-layer design, component boundaries, data and contract flow, and binding invariants that protocol and security specifications refine.	normative	verified	draft
RS-DM-MANIFEST	RS-DM-MANIFEST: Registry Manifest portable metadata data modelThe data model for a Registry Manifest portable metadata manifest: schema version, runtime-binding boundary, catalog collections, reference integrity, governed evidence metadata, evidence-offering access discovery, discovery-bundle digests, and strict unknown-key rejection.	normative	verified	draft
RS-DOC	RS-DOC: Documentation frameworkHow the formal specification layer of the registry stack is structured, identified, versioned, and governed. The conventions every other specification builds on.	normative	verified	draft
RS-OP-POSTURE	RS-OP-POSTURE: Relay operational postureThe normative operational contract for a Relay deployment: the liveness and readiness probes, how readiness composes audit, source, and issuer state, the audit sink as a serving precondition, runtime limits and quotas, bounded operational logging, and startup verification of the sealed package.	normative	verified	draft
RS-PR-EVIDENCE	RS-PR-EVIDENCE: Evidence Gateway protocolThe normative HTTP protocol contract for Evidence Gateway: discovery, authentication, assurance profiles, the closed request contract, acceptance definitions, minimum disclosure, response formats, problem reporting, audit gates, and immutable deployment input.	normative	verified	draft
RS-PR-RELAY	RS-PR-RELAY: Relay protocolThe normative HTTP protocol contract for Relay: the fixed route set, the Registry Core response envelope, access and disclosure profiles, cursor pagination, the Point and SDMX read profiles, and the audit and error behavior every request carries.	normative	verified	draft
RS-PR-RELAYCTL	RS-PR-RELAYCTL: relayctl contractThe normative contract for relayctl: seven commands, the schema-inspection boundary, compilation profiles, the sealed package output, exit statuses, and the process boundary that keeps relayctl out of the serving path.	normative	verified	draft
RS-SEC-G	RS-SEC-G: Registry family security modelThe cross-cutting security model for the registry stack: shared security primitives, authentication and authorization, verification-key publication, audit, replay protection, and the operator boundary.	normative	verified	draft
RS-TERMS	RS-TERMS: Terms and abbreviationsNormative definitions for the terms used across registry stack specifications, distilled from the documentation glossary.	normative	verified	draft

Generated from the frontmatter of every specification document.

How to read the register

Every specification carries three independent axes. RS-DOC defines them in full; in short:

• Category is the document’s role. normative defines required behavior; informative explains it. A requirement only binds when it is in a normative document.
• Evidence is how true the document is against shipped code. verified is backed by code, tests, fixtures, or generated artifacts; partial mixes shipped and target behavior; aspirational describes a target state that is not built yet. A normative plus aspirational document is the design for behavior that does not exist yet, and it says so at the top.
• Status is the lifecycle state: draft, current, historical, or deprecated.

Start with RS-DOC for how this layer works, then RS-TERMS for the shared vocabulary the other specifications build on.