RS-TERMS: Terms and abbreviations

This document establishes the shared vocabulary for the registry stack formal specification layer. It defines terms used normatively in other specifications, records the product names and their repository identifiers, and maps the external standards that the stack’s own terms extend or adopt. Implementors, auditors, and governance teams who read or write registry stack specifications SHOULD treat the definitions here as binding, and a specification SHOULD cite RS-TERMS when referencing a defined term rather than re-defining it locally.

REQ-TERMS-001: The definitions in this document apply wherever a registry stack specification uses the term. A specification SHOULD cite RS-TERMS when importing vocabulary defined here.

The key words in this document are interpreted per RS-DOC Section 2.

Version history

Version	Date	Status	Change
0.1.0	2026-06-13	draft	Initial terms, distilled from the documentation glossary.
0.2.0	2026-06-13	draft	Added the adoption mode term (Section 3) and the documentation declaration terms, layer and audience (Section 6).
0.3.0	2026-06-20	draft	Added governed Relay PDP and PDP enforcement terms.
0.3.1	2026-06-20	draft	Added PDP, PEP, trust context, source binding, route identity, checked scope, ecosystem binding, ODRL enforcement profile, audit provenance, and fail-closed definitions.
0.3.2	2026-06-22	draft	Added delegated subject access and clarified direct subject access.
0.4.0	2026-07-07	draft	Renamed the static discovery bundle consistently, added the DID issuer-mode security qualifier, corrected signed response credential gating and disclosure profile casing, added SDMX and eight vocabulary entries (matching policy, claim definition, credential profile, source connector, source adapter sidecar, static-peer federation, issuer mode, JWKS), extended standards_referenced, and aligned subject access terminology with the then-current Registry Notary product specification, since retired.
0.5.0	2026-07-09	draft	Marked Registry Relay signed response credentials and issuer mode as removed before 1.0.
0.6.0	2026-07-13	draft	Replaced direct Registry Notary source connectors and sidecars with compiler-pinned Relay consultations and Registry Stack project authoring terms. Registry Notary has since been retired.
0.6.1	2026-07-14	draft	Added the complete Registry Stack project-authoring vocabulary and clarified compiler-derived credential membership.
0.7.0	2026-07-16	draft	Defined the formal stack as four products and classified Solmara Lab as a separate adopter demo.
0.8.0	2026-07-19	draft	Defined the registry-backed, issuer-initiated OID4VCI profile and its algorithm, transaction-code, and non-conformance boundaries.
0.9.0	2026-08-03	draft	Reseated the vocabulary on Registry Relay, Registry Evidence, and Registry Mint, added the Registry Evidence assertion terms, and marked the retired Registry Notary terms as retired.
0.10.0	2026-08-07	draft	Replaced the Registry Evidence requirement’s single-source field with its closed single or search-then-fetch acquisition.
0.11.0	2026-08-10	draft	Scoped the data-only SDMX definition to Relay 1.0 and added the separate Relay V2 read profile.
0.12.0	2026-08-11	draft	Reseated the Relay vocabulary on the Relay V2 runtime and relayctl. Removed the Relay V1 project-authoring terms, the gateway adapter terms, and the governed PDP runtime terms, none of which a maintained component implements, retired the cross-product Registry Stack project in favour of the per-deployment authoring project the tooling names, and added the packaging, access, disclosure, Registry Core, Point, and statistical-dataset vocabulary the current runtime uses.
0.13.0	2026-10-03	draft	Retired current Relay vocabulary after version 0.38.0, retained its published identifiers as historical terms, and added Base Registry Engine vocabulary.

1. Products

The current registry stack includes the products defined here and the additional focused runtime products defined by RS-ARC-G. Product names are Title Case. Repository slugs appear in monospace and are lowercase.

Registry Platform (registry-platform): Shared Rust workspace for registry security and operational primitives, including auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, Selective Disclosure JWT Verifiable Credential (SD-JWT VC) helpers, and test fixtures. Consumed by the runtime services.

Registry Manifest (registry-manifest): Rust workspace for modeling, validating, and rendering standards-facing service, registry, form, and policy metadata. It provides registry-manifest-core and registry-manifest-cli, reads no production registry data, and grants no runtime authority.

Base Registry Engine (BReg) (registry-breg): PostgreSQL-backed runtime that compiles a registry project into governed entities, fields, relationships, operations, access profiles, changes, history, and events. It owns the records it stores and admits reads and mutations only through the compiled model. Specification prose shortens the name to BReg.

Registry Evidence (registry-evidence): Single-crate minimum-disclosure assertion service and its evidence binary. Given authenticated authority, an authorized purpose, and a predefined requirement, it returns a signed assertion that answers the requirement rather than the source record. Registry Evidence has no credential issuance lifecycle.

wallet delivery front end (registry-evidence-oid4vci): Supporting service outside the runtime product patterns. It speaks OID4VCI 1.0 Final to a holder wallet and delivers a Registry Evidence-signed credential over it. It signs no credential, holds no signing key and no holder private key, and adds no Registry Evidence semantics of its own.

Solmara Lab (solmara-lab): Separately maintained adopter demo for the fictional Republic of Solmara. It runs published Registry Stack images in local and hosted topologies. Solmara Lab is not a formal Registry Stack product and has no conformance weight in the Registry Stack specifications.

2. Assertion and credential terms

assertion: The stateless signed payload Registry Evidence returns for one request. It answers a requirement and carries no source record. Its member set is closed by the frozen contract products/evidence/contracts/evidence.schema.yaml, which names the supported requirement, the conformant Evidence Type, issuer and provider, issue, observation, and validity instants, purpose, audience, configuration revision, role-bound subject bindings, and supported values. A holder-bound assertion carries neither audience nor request nonce, because it names no relying party to echo them to; the two members are present together or absent together. An assertion has no lifecycle: there is no issuance session, no status list, and no revocation. Registry Stack product term.

acceptance definition: One complete authored answer path in a Registry Evidence deployment project: a source with its request and response schema, the extraction script, the fact schema and any codelist, the derivation, the requirement with its concept and disclosure guard, the authority grant that permits it, and the synthetic fixture cases that prove it. Registry Evidence Version 1 freezes four coequal acceptance definitions: adult status, residence region, professional licence status, and legal-parent relationship. No acceptance definition is privileged in the runtime, so none of them MUST become a Rust domain type, a built-in operation, or a special route. Registry Stack product term.

requirement: The predefined, versioned question one Registry Evidence request names, declared in the immutable bundle with its identifier, kind, closed single or search-then-fetch acquisition, authorized purposes, subject roles and selector profiles, reference frameworks, Evidence Type, validity, derivation, concepts, fixtures, and disclosure guard. Only predefined, versioned requirements can be evaluated, and to a caller lacking authorization an unknown requirement MUST be indistinguishable from an unauthorized one. The CCCEV term is adopted for the same idea.

purpose: The authorized reason a caller gives for one Registry Evidence request. A purpose is a configured code drawn from the requirement’s declared purposes and from the caller’s grant, never caller-defined prose, and it forms part of the single authorization decision. It is echoed into the assertion and MUST NOT narrow disclosure: a use case that justifies a coarser answer needs its own requirement. Registry Stack product term.

minimum disclosure: The rule that one Registry Evidence response carries the smallest sufficient answer to one requirement and never the source record. The assertion payload is closed against additional properties, subject selector profiles and selector values MUST NOT appear in it, and the output gate admits only the exact concept identifiers and value forms the requirement declares. Registry Stack product term.

access token: The bearer credential a caller presents to Registry Evidence. Registry Evidence accepts one authentication kind whose issuer, audiences, accepted token types, algorithms, key set location, and claim names are fixed in the immutable bundle, and it reads authority only from those configured claim names. The deployment’s configured issuer supplies such tokens. Caller-supplied data outside the verified token MUST NOT create authority.

subject binding: The opaque, role-bound handle an assertion carries in place of a subject’s selector values. It is derived by HMAC under a deployment secret over one canonical scope tuple: binding-key version, operator trust domain, binding scope, purpose, subject role, selector profile, and the complete canonical selector field set and its values. A relying party cannot recompute a binding under either mode and MUST pin the expected bindings from independent trusted state. Registry Stack product term.

subject binding mode: Which value the binding scope takes. The vocabulary is closed at two values, audience-scoped and holder-bound, and it has no default. The requirement declares it inside the immutable bundle; absence means audience-scoped, and no caller input selects a mode. Each mode derives under its own domain constant, so the two derivations cannot collide, and both emit into the one urn:evidence:subject namespace. Registry Stack product term.

holder: The party whose public key a caller supplies on a Registry Evidence request. Under audience-scoped the key is optional and inert: Registry Evidence echoes it into the SD-JWT VC cnf claim and does nothing else with it, so there is no holder-binding ceremony, no key-binding JWT, and no presentation verification. Under holder-bound at least one key is required, cnf is required in the credential, and the key’s RFC 7638 thumbprint is the binding scope. In both modes the key MUST NOT reach authorization, selectors, scripts, source requests, or audit, and no private key member is accepted anywhere.

key-binding JWT: The JWT a holder appends to a presentation, defined by RFC 9901 section 4.3, signed by the private key of the credential’s cnf and covering the presented bytes, the audience, and the nonce the relying party chose. Registry Evidence never appends one; the holder does, and the relying party verifies it. A verified key-binding JWT proves possession at signing time and nothing more. Comparing a nonce is not consuming it, RFC 9901 section 7.3 places the challenge lifecycle in the surrounding protocol, and no Evidence credential or presentation surface consumes the nonce or prevents replay.

presentation: A holder-bound credential in the compact serialization with a key-binding JWT after the last tilde and no trailing tilde. An issued credential ends in a trailing tilde and is therefore not a presentation; a stored credential offered as one MUST be refused rather than verified without possession. Presentation verification fails closed, checks key binding before any policy comparison, and never reports a presentation whose issuer signature verifies and whose key binding does not as an issuer-only success.

SD-JWT VC: Selective Disclosure JWT Verifiable Credential (IETF draft). Registry Evidence serializes the same stateless assertion as an SD-JWT VC under the frozen profile products/evidence/contracts/sd-jwt-vc-profile.yaml, when the immutable bundle and the matched grant both permit that response format. Under audience-scoped the serialization is meaningful only to the relying party the assertion names. A requirement declaring holder-bound narrows its own formats to this serialization and the batch envelope, under the frozen profile products/evidence/contracts/holder-bound-profile.yaml. Neither mode is a credential lifecycle, and full SD-JWT VC conformance is not claimed. Media type: application/dc+sd-jwt.

batch release: One holder-bound response carrying one credential member per distinct holder key, under a ceiling the immutable bundle declares. It is one authorization decision, one source acquisition, and one derivation, then per-member construction and signature; each member carries its own subject binding, confirmation key, identifier, and independent disclosure salts. A failure on any member releases nothing, and the whole release is recorded by exactly one terminal disclosure-release event. The envelope is issuance-only and is never an input to verification. Media type: application/vnd.registrystack.evidence.batch+json. Registry Stack product term.

wallet: A holder-owned application that stores credentials and presents them to verifiers. The Registry Evidence runtime integrates with none; the separate registry-evidence-oid4vci front end delivers a credential to one over OID4VCI. Wallet onboarding, wallet attestation, trust-list membership, and holder key generation, holding, escrow, or recovery by the service remain non-goals under both subject binding modes. The holder-bound mode defines what a relying party verifies when a holder presents a credential; it does not make Registry Evidence a wallet counterparty, and no test in this repository covers a wallet holding or presenting a Registry Evidence credential.

OID4VCI: OpenID for Verifiable Credential Issuance. The Registry Evidence runtime implements it in no part, and OID4VCI in any part is a frozen Registry Evidence Version 1 non-goal under both subject binding modes, so no serialization has a credential offer, pre-authorized code, authorization or token endpoint, c_nonce, credential endpoint, deferred issuance, or wallet grant. The separate registry-evidence-oid4vci front end speaks it, which is why it is a separate service.

eSignet: Open-source identity and authentication service (part of MOSIP). No stack service calls it. Registry Evidence authenticates callers against one configured OIDC issuer and key set named in its immutable bundle and names no specific identity product. The integration runs the other way: a separately maintained eSignet provider authenticates a citizen against a Base Registry Engine (BReg) registry through one governed lookup carrying a token from its configured OAuth issuer, which makes eSignet an ordinary governed client of a registry. See Authenticate citizens with eSignet. Not a Registry Stack product term.

3. Metadata and standards terms

metadata manifest: Portable metadata.yaml using schema version registry-manifest/v1 to describe a registry through its catalog and defined collections. It MUST NOT contain runtime bindings such as database paths, listener addresses, source credentials, or secret values. Registry Stack product term.

static discovery bundle: Manifest-generated directory containing catalog.json, DCAT, BRegDCAT-AP, CPSV-AP, SHACL, JSON Schema, OGC Records, evidence-offering, policy, and embedded SKOS-shaped codelist metadata. It can be hosted as static files and grants no runtime authority. Registry Stack product term.

compiled registry: The canonical Base Registry Engine (BReg) model produced from a registry project. The active package uses that model to define its Record types, fields, relationships, Actions, Proposal policies, access profiles, and generated API artifacts. Registry Stack product term.

operation: A named BReg capability compiled from a registry project. Operations include governed record reads and writes, Action invocation and Start, and Proposal lifecycle transitions. An access profile states which operations a caller may use. Registry Stack product term.

access profile: A named BReg grant stating which scopes, purposes, claims, operations, fields, and rows a caller may reach. Registry Stack product term.

row boundary: A BReg access-profile rule that binds a record field to a verified token claim, so a request reaches only matching rows. A caller-supplied request value does not satisfy the boundary. Registry Stack product term.

statistical dataset: A BReg root-project declaration of a fixed count population, calendar period rule, and closed dimensions. Authenticated access profiles separately grant exact live reads, publication, and released-data reads. Registry Stack product term.

standards-shaped metadata: Machine-readable metadata emitted through formats such as Data Catalog Vocabulary (DCAT), Core Public Service Vocabulary Application Profile (CPSV-AP), Core Criterion and Core Evidence Vocabulary (CCCEV), Shapes Constraint Language (SHACL), JSON Schema, Open Digital Rights Language (ODRL), OpenAPI, OGC API Records, and SKOS-shaped codelist metadata. Registry Stack product term.

evidence type list: A Core Criterion and Core Evidence Vocabulary (CCCEV) list of evidence types that satisfy a requirement. In Registry Manifest, one list is one grouped option; multiple lists on the same requirement are alternatives. The CCCEV term is adopted directly.

The Registry Manifest reference owns the current manifest key and field inventory used by the terms below.

deployment project: The directory a Registry Evidence operator authors and mounts: a runtime.yaml file holding process-local bindings, and a bundle/ directory holding the governed configuration, scripts, schemas, codelists, and fixtures. The bundle is loaded read-only at startup, so a new revision is a new deployment rather than a live change. Registry Stack product term.

JWKS: JSON Web Key Set. Registry Evidence publishes its signing keys without authentication at GET /.well-known/evidence/jwks.json so a verifier can obtain the public key without holding a credential.

source: An authoritative system or immutable extract a product reads through its own bounded adapter. Registry Evidence fixes its source request in the governed bundle. BReg owns its PostgreSQL record store and may itself be an HTTP source for another product without transferring its authorization decision. Registry Stack product term.

deployment: An operated set of instances of one product under one reviewed configuration and operator boundary. Each product activates its own configuration; there is no cross-product atomic activation coordinator. Registry Stack product term.

trust domain: The institutional boundary whose operators, runtime identities, policy, keys, and approval govern one deployment. A geographic jurisdiction may contain several trust domains, and a trust domain need not represent a country. Registry Stack product term.

generated artifact: A deterministic machine-readable file derived from governed input, such as Registry Manifest metadata output or BReg OpenAPI and JSON Schema. The owning product defines the artifact’s authority, publication, and regeneration rules. Registry Stack product term.

DCAT: Data Catalog Vocabulary. W3C recommendation. Registry Manifest emits DCAT-shaped JSON-LD catalogs. Spell out on first use per document.

BRegDCAT-AP: SEMIC profile of DCAT-AP for base registries. Registry Manifest emits BRegDCAT-AP-shaped registry and data-service metadata.

CPSV-AP: Core Public Service Vocabulary Application Profile. Registry Manifest emits CPSV-AP service catalogue JSON-LD.

CCCEV: Core Criterion and Core Evidence Vocabulary. Registry Manifest emits CCCEV-shaped requirement, evidence type, and evidence type list metadata. Registry Evidence maps its assertion payload onto CCCEV terms under the frozen mapping products/evidence/contracts/cccev-field-mapping.yaml, with named Registry Evidence extensions where CCCEV has no counterpart.

SHACL: Shapes Constraint Language. W3C recommendation. Registry Manifest emits SHACL node shapes for entity validation.

ODRL: Open Digital Rights Language. W3C recommendation. Registry Manifest emits ODRL Offer documents for dataset-scoped descriptive policies and validates the ODRL enforcement profile an evidence pack declares. Publishing or validating an ODRL policy document is not runtime enforcement, and no maintained runtime evaluates ODRL terms.

JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Registry Manifest uses it for catalog, service, evidence, codelist, and policy render output.

OGC API Records: Open Geospatial Consortium API specification for records. Registry Manifest renders and publishes an OGC Records item collection as static metadata. No maintained runtime serves OGC API Records routes.

SKOS: Simple Knowledge Organization System. Registry Manifest currently emits flat SKOS-shaped skos:ConceptScheme and skos:Concept nodes for codelists inside SHACL and BRegDCAT/DCAT-shaped outputs. It does not yet publish a standalone SKOS artifact.

PROV-O: W3C Provenance Ontology. Currently listed as design influence (inspired_by). Provenance-shaped concepts appear in audit fields, but no PROV-O vocabulary terms are emitted as JSON-LD at reviewed commits.

claim level: The evidence discipline these docs use for standards claims: implements, emits, maps_to, aligns_with, inspired_by, or compares_against. Applies to entries in the standards register and is used to characterize a product’s relationship to an external standard without overstatement.

adoption mode: The technical integration pattern a registry stack surface takes toward an external standard, recorded per entry in the standards register: adopted (used directly, as the standard intends, for the part used), profiled (a constrained or profiled subset), adapted (reached through an adapter or connector at a boundary), mapped (the standard’s terms mapped onto the stack’s own), or not adopted (referenced, compared against, or a design influence only, with no implemented contract). Adoption mode is orthogonal to claim level: claim level grades how strongly a relationship is evidenced, adoption mode names what the relationship is. A standard can be not adopted and still aligns_with the stack, meaning the design is consistent with it but the stack does not implement it as a contract. Registry Stack documentation term.

4. Governance and safeguards terms

governed evidence: Evidence metadata bound to a governed evidence ecosystem binding (type: governed-evidence). In a metadata manifest, governed evidence requires evidence-pack metadata such as pack identity, source basis, semantic profile, evidence envelope, required PDP gates, allowed outputs, policy identity, policy hash, and ODRL enforcement profile. Registry Manifest validates that metadata. It is portable description, not runtime behavior: no maintained runtime consumes an evidence pack to reach an access decision.

ecosystem binding: Manifest-level binding that connects an external ecosystem profile or governed evidence pack to a described runtime surface. A governed evidence ecosystem binding names the evidence-pack metadata and policy identity, and naming them binds no maintained runtime to enforce them. Registry Stack product term.

PDP gate: One of the named checks a governed evidence pack must declare in its metadata, including purpose, jurisdiction, legal basis, consent, authority basis, requester identity, subject identity, subject relationship, assurance, source binding, source freshness, requested disclosure, credential format, and route scope. Registry Manifest requires the complete set to be declared. Declaring a gate records an obligation for whichever system enforces the pack; it does not make a maintained runtime evaluate it.

policy hash: Lowercase sha256: digest that binds a governed evidence policy identity to canonical policy bytes or to an externally supplied policy artifact. Registry Manifest validates digest shape and verifies the digest when an inline evidence-pack policy object is present.

source binding: The declared PDP gate that names which configured source service, resource, or claim binding a governed decision is allowed to use. It exists so a policy and an audit record can distinguish one backend source from another. Registry Stack product term.

source freshness: The declared PDP gate that compares trusted source metadata or trusted source-observation context against a maximum age. Registry Stack product term.

safeguards: Product-owned controls that bind an operation to verified authority, reviewed configuration, bounded input and output, and the product’s audit contract. BReg admits mutations only through compiled operations and authorized access profiles. Registry Evidence releases only the concepts and value forms declared by the matched requirement and grant. Registry Stack product term.

executable safeguards: Runtime-enforced safeguards such as BReg access profiles and row boundaries, Registry Evidence’s fixed requirements and disclosure guards, fail-closed audit events, and closed machine-readable contracts. Registry Stack product term.

distributed custody: The architectural premise that each authority retains control of its own registry data. The registry stack provides the API surface for lawful exchange between authorities; it does not aggregate data into a central system. Equivalent terms include data sovereignty (Gaia-X, IDS, EU dataspaces vocabulary), subsidiarity (governance literature), and federated custody. Registry Stack product term.

purpose-bound request: A request whose authorization decision includes one governed purpose. For Registry Evidence, purpose is a configured code shared by the requirement and matched grant. For BReg, an access profile may constrain a compiled operation by purpose. Caller-defined prose creates no authority. Registry Stack product term.

minimized evidence: An evidence response shaped by data minimization, selective disclosure, or verifiable attestation. The response can be narrower than the full source record when the configured use case supports that pattern. Registry Stack product term.

reviewability: The commitment that a product claim has an artifact a third party can inspect. Examples include Registry Manifest’s static metadata, BReg packages and generated API schemas, Registry Evidence contracts and invariant tests, audit schemas, and public verification keys. Registry Stack product term.

interoperability: The commitment that published surfaces use documented, standards-shaped contracts instead of deployment-private formats. Registry Manifest renders portable metadata, BReg publishes generated OpenAPI and JSON Schema artifacts, and Registry Evidence publishes its frozen assertion and verifier contracts. Registry Stack product term.

fail closed: Security posture where a missing, malformed, unsupported, stale, or unauditable input results in refusal rather than release. Registry Stack product term.

DPI: Digital Public Infrastructure. Shared, interoperable digital systems (identity, payments, data exchange) deployed at population scale to support public service delivery. The registry stack covers governed registries, supporting workflows, and minimum-disclosure evidence exchange within a DPI deployment.

Retired vocabulary

Registry Relay and relayctl name the product and adopter tool retired after Registry Stack 0.38.0. Their identifiers remain reserved for historical resolution and are not reusable by another product.

Relay’s resource, disclosure profile, and row binding terms described its compiled read-only publication contract. They do not name current BReg or Registry Evidence contract types.

The Relay-only meanings of governed contract, deployment binding, compiled Registry, sealed package, package digest, source profile, Registry Core record context, consultation, generated artifact, statistical dataset, SDMX read profile, Point profile, authoring project, issuer mode, signed response credentials, GeoJSON, JSON-FG, and SDMX are retired with the product. General uses of generated artifact, GeoJSON, JSON-LD, SHACL, JSON Schema, and SDMX remain governed by their owning current product or external standard. Archived docsets preserve the definitions published with their releases.

5. Abbreviations

This table maps each acronym used in registry stack documentation to its expansion. The first occurrence of each acronym in any document SHOULD be followed by its expansion in parentheses.

Acronym	Expansion
BRegDCAT-AP	Base Registry DCAT Application Profile
CCCEV	Core Criterion and Core Evidence Vocabulary
CPSV-AP	Core Public Service Vocabulary Application Profile
CRS84	WGS 84 coordinate reference system in longitude, latitude order
DCAT	Data Catalog Vocabulary
DID	Decentralized Identifier
DPI	Digital Public Infrastructure
JSON-FG	OGC Features and Geometries JSON
JSON-LD	JSON Linked Data
JWKS	JSON Web Key Set
JWS	JSON Web Signature
ODRL	Open Digital Rights Language
OID4VCI	OpenID for Verifiable Credential Issuance
OGC API Records	Open Geospatial Consortium API - Records
PDP	Policy Decision Point
PROV-O	W3C Provenance Ontology
SD-JWT VC	Selective Disclosure JWT Verifiable Credential
SHACL	Shapes Constraint Language
SKOS	Simple Knowledge Organization System
SDMX	Statistical Data and Metadata eXchange

6. Documentation declaration terms

These terms classify a documentation page so a reader, human or AI agent, can tell from the page frontmatter where it sits and whom it serves. They are recorded in the optional layer and audience frontmatter keys defined by RS-DOC. Both keys take a list, because a specification is frequently cross-cutting; a page that spans every layer omits layer rather than list all of them. The vocabulary mirrors the layer and surface vocabulary the registry stack already uses, so documentation does not invent a parallel taxonomy.

layer: The stack layer or layers a page documents. The defined values are:

• metadata: portable descriptive metadata, including Registry Manifest and static discovery.
• consultation: retired for current pages; it named Relay’s read-only publication surface.
• evaluation: Registry Evidence requirement evaluation and assertion release.
• credential: retired for current pages; it named a retired credential-issuance product.
• federation: retired for current pages; it named retired delegated peer evaluation.
• administration: operator-facing configuration, key, trust, and lifecycle surfaces.
• operations: runtime operation and recovery, including deployment, audit, backup, and runbooks.

audience: The reader role or roles a page serves. The defined values are integrator (a developer integrating against a stack surface), operator (an operator configuring or running a deployment), maintainer (a contributor to a stack component), specification editor (an author of this formal layer), and tooling (an AI coding agent or other automated reader that consumes the page as input).

Evidence

This specification is verified: the definitions are distilled from published reference material a reader can inspect, per RS-DOC REQ-DOC-014.

The glossary is the approachable form of this vocabulary; RS-TERMS is authoritative where the two disagree. The standards register records the adoption mode and evidence for external standards. RS-ARC-G owns the product and layer boundaries, RS-DM-MANIFEST and the Manifest reference own portable metadata, and RS-PR-EVIDENCE owns the Evidence protocol vocabulary.

Next

• RS-DOC defines the documentation framework and the conventions every specification in this layer follows.
• The glossary provides the same vocabulary in a friendlier reference format. RS-TERMS is the authoritative source when the two disagree; practical docs use the glossary for approachable explanation.