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 a reader should know which one they are in:

• 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) stays in the internal repository. Formal docs are distilled from it, never copied out of it.

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, and that is a bug in the practical page to be fixed. 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 architecture The 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-CLAIM	RS-DM-CLAIM: Registry Notary claim definition data model The data model for a Registry Notary claim definition: its identity, inputs, source bindings and matching policy, rule, disclosure policy, response formats, credential eligibility, and batch behavior, and the invariants a conforming deployment enforces.	normative	verified	draft
RS-DM-MANIFEST	RS-DM-MANIFEST: Registry Manifest portable metadata data model The data model for a Registry Manifest portable metadata manifest: its schema version and identity, the runtime-binding boundary that keeps it portable, the catalog and top-level collections that describe a registry, reference integrity and identifier constraints, grouped evidence, federation discovery metadata, the standards-shaped render set, the publication bundle and its digests, and the additive-evolution rule a conforming producer and reader follow.	normative	verified	draft
RS-DOC	RS-DOC: Documentation framework How 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-PR-NOTARY	RS-PR-NOTARY: Registry Notary protocol The normative HTTP protocol contract for Registry Notary: discovery, authentication, claim evaluation, disclosure semantics, response formats, credential issuance (direct and OID4VCI), delegated evaluation, and audit behavior.	normative	verified	draft
RS-PR-RELAY	RS-PR-RELAY: Registry Relay protocol The normative HTTP protocol contract for Registry Relay: the configuration-driven service model, authentication and per-dataset scopes, consultation and aggregate routes, scoped metadata publication, evidence offerings, signed response credentials, and audit behavior.	normative	verified	draft
RS-SEC-G	RS-SEC-G: Registry family security model The cross-cutting security model for the registry stack: the shared security primitives, authentication and authorization, verification-key publication, the audit obligation, federation trust, and the operator boundary that the protocol specifications refine.	normative	verified	draft
RS-TERMS	RS-TERMS: Terms and abbreviations Normative 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.