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, Evidence Gateway, and Registry Mint, added the Evidence Gateway assertion terms, and marked the retired Registry Notary terms as retired.
0.10.0	2026-08-07	draft	Replaced the Evidence Gateway 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.

1. Products

The registry stack comprises four formal products: Registry Platform, Registry Relay, Registry Manifest, and Evidence Gateway. Product names are Title Case. Repository slugs appear in monospace and are always lowercase. The phrase “registry stack” (lowercase) refers to that four-product ensemble together with the adopter tooling and supporting services this section names.

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 Relay (registry-relay): Contract-compiled, read-only consultation runtime and the relay binary. It serves a fixed route set over one sealed package holding an adopter’s governed contract, the compiled Registry derived from it, and every artifact generated from that Registry. Sources are SQLite databases read through the shared bounded read-only boundary. Relay exposes no write route, no administrative route, and no reload endpoint: a governed change is a new package and a new process. Specification prose shortens the name to Relay.

relayctl: The adopter command line beside Relay, shipped from the same product. It initializes an authoring project, inspects SQLite structure without reading row values, compiles and validates a project, generates deterministic artifacts, runs offline fixtures, classifies the change between two project revisions, and builds the sealed package. Every operation links the same shared library the runtime uses, so the authoring path and the serving path cannot diverge. relayctl starts no process, reaches no running deployment, reads no environment variable, and signs nothing.

Registry Manifest (registry-manifest): Rust workspace for modeling, validating, and rendering standards-facing service, registry, form, and policy metadata without running Relay. Provides a library (registry-manifest-core) and a command-line interface (registry-manifest-cli).

Evidence Gateway (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. Evidence Gateway has no credential issuance lifecycle.

Registry Mint (registry-mint): Supporting service, not a fifth product pattern. It issues short-lived, audience-bound access tokens to registered machine clients so a resource server such as Evidence Gateway can require signed tokens without a general-purpose identity provider. The dependency runs one way only: Registry Mint’s tests drive Evidence Gateway’s authenticator, and Evidence Gateway does not depend on Registry Mint.

wallet delivery front end (registry-evidence-oid4vci): Supporting service in the same sense as Registry Mint. It speaks OID4VCI 1.0 Final to a holder wallet and delivers an Evidence Gateway-signed credential over it. It signs no credential, holds no signing key and no holder private key, and adds no Evidence Gateway 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 Evidence Gateway 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 an Evidence Gateway 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. Evidence Gateway 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 Evidence Gateway 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 Evidence Gateway 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 Evidence Gateway 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 Evidence Gateway. Evidence Gateway 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. Registry Mint issues such tokens; any issuer writing the same claims serves equally well. 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 an Evidence Gateway request. Under audience-scoped the key is optional and inert: Evidence Gateway 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. Evidence Gateway 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 part of this stack performs replay prevention.

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). Evidence Gateway 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.

DID: Decentralized Identifier. W3C DID Core 1.0. Registry Relay no longer publishes a DID document, and no current stack service resolves, publishes, or issues DIDs. Evidence Gateway accepts a holder public key as a bare JSON Web Key, not as a DID.

signed response credentials: Removed Registry Relay feature that attached a W3C Verifiable Credentials Data Model (VCDM) 2.0 VC-JWT signed credential to entity record and aggregate responses. Registry Relay no longer accepts the legacy provenance configuration key, no longer serves /.well-known/did.json, /schemas/{claim_type}/{version}, or /contexts/{vocab}/{version}, and no longer returns application/vc+jwt. No current stack service issues W3C VCDM credentials.

wallet: A holder-owned application that stores credentials and presents them to verifiers. The Evidence Gateway 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 Evidence Gateway a wallet counterparty, and no test in this repository covers a wallet holding or presenting an Evidence Gateway credential.

OID4VCI: OpenID for Verifiable Credential Issuance. The Evidence Gateway runtime implements it in no part, and OID4VCI in any part is a frozen Evidence Gateway 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 current stack service integrates with it. Evidence Gateway authenticates callers against one configured OIDC issuer and key set named in its immutable bundle and names no specific identity product. Not a Registry Stack product term.

3. Metadata and standards terms

metadata manifest: Portable metadata.yaml document using schema version registry-manifest/v1 that describes a registry through its catalog and defined collections. The Registry Manifest reference is authoritative for the current top-level keys and field schemas. A metadata manifest MUST NOT include Relay deployment bindings such as source paths, view names, or scopes. Registry Stack product term.

governed contract: The authored kind: RegistryContract document, at apiVersion: relay.registrystack.org/v2alpha1, that declares one Relay deployment’s registry identity, sources, resources, operations, access profiles, disclosure profiles, and statistical datasets. It rejects unknown fields at every nested structure. Registry Stack product term.

deployment binding: The deployment-local half of a Relay deployment, authored as a closed kind: RelayRuntime document at the same apiVersion. It carries the listener, the identity issuer, source file paths, the audit destination, and quotas, and it rejects every governed field, so an operator cannot widen governed intent through deployment configuration. Replaces the Relay 1.0 term runtime binding. Registry Stack product term.

compiled Registry: The canonical model derived from a governed contract together with the reviewed source schema observations recorded beside it. Every generated artifact derives from the compiled Registry, and the runtime re-derives both at startup rather than trusting the packaged copy. Registry Stack product term.

sealed package: The one directory a Relay process serves: the authored contract, the compiled Registry derived from it, and every generated artifact, each bound to a SHA-256 digest over its canonical bytes under one manifest. It is the governed trust root, so Relay verifies it, and re-derives the compiled Registry and each artifact byte for byte, before it opens an issuer connection, an audit sink, a source, or a listener. Registry Stack product term.

package revision: The SHA-256 digest over the canonical JSON of a sealed package manifest. It is an integrity digest, not an authenticity proof: any party can recompute it, Relay packages are unsigned, and a matching revision is no evidence of who produced the package. Registry Stack product term.

source profile: Which of two reading disciplines a declared Relay source follows. snapshot names a source whose bytes are fixed for the life of the deployment and confirmed unchanged at startup; live-read-only names a source that may change underneath a running process and is still read read-only. The vocabulary is closed at these two values, and every source declares exactly one. Registry Stack product term.

resource: A named domain collection a governed contract declares, bound to exactly one reviewed view in one declared source. Table names, SQL text, and hidden source columns never reach the public surface. Registry Stack product term.

operation: One reachable read on a resource: a record list, a single record read, an exact lookup by declared match values, or a declared bounded search. An operation carries one or more access profiles and its own page-size bounds. Registry Stack product term.

access profile: The compiled unit that pairs an access rule with a disclosure profile, so the authorization decision and the disclosure decision are one artifact rather than two independent runtime lookups. An access rule is either Public, requiring no credential, or Protected, requiring an OpenID Connect (OIDC) bearer access token carrying the rule’s scope and optionally a declared purpose and a row binding. A caller MAY select a profile with the accessProfile query parameter; selection narrows what a request can reach and never widens it. Registry Stack product term.

disclosure profile: The enumerated set of properties a response may carry, together with the maximum handling classification those properties permit. It bounds the response before any caller preference applies: the fields parameter narrows within the selected profile and can never reach a property the profile does not disclose. A transform the profile declares is applied before the value leaves the process and is recorded in the request’s audit record. Registry Stack product term.

row binding: The restriction that limits an operation’s rows to those the authenticated caller is entitled to. The binding authority comes from the verified token, either from the principal itself or from one named verified claim; a caller-supplied request value never satisfies it. Registry Stack product term.

Registry Core record context: The fixed context every Relay record carries alongside its domain payload: registryIdentifier, recordIdentifier, revisionIdentifier, lifecycleState, schemaReference, semanticModelReference, authorityIdentifier, and recordedAt, with the deployment’s own values confined to domainData. Field selection narrows only domainData, so a caller never receives a value without the identity, revision, lifecycle, schema, and authority context that qualifies it. Registry Stack product term.

consultation: Relay’s capability family for record reads, covering the list, single-read, lookup, and search operations a governed contract declares over its resources. The word names that family and its problem codes, consultation.denied and consultation.rate_limited, not a separately authored artifact. Registry Stack product term.

generated artifact: A JSON Schema, SHACL shape, JSON-LD vocabulary or context document, audit event schema, or OpenAPI description derived from the compiled Registry and carried inside the sealed package. Relay generates no artifact at request time. An operator-only artifact is never served, and an operation-bound artifact reaches only a caller its bound operation and access profile authorize. Registry Stack product term.

statistical dataset: A governed, pre-aggregated dataset a Relay contract may declare, served through the SDMX read profile. It carries one fixed access rule for the whole dataset and carries no record access profile, disclosure profile, field selection, or row binding, which are Record-surface constructs. A deployment that declares none reports the aggregate-data capability family as unsupported. Registry Stack product term.

SDMX read profile: Relay’s profiled SDMX REST 2.2.2 read subset over statistical datasets. It serves keyed dataflow data, dataflow data with the key omitted, dataflow structure, and data structure definition, and nothing else: no schema resource, no availability resource, and no write. Registry Stack product term.

Point profile: The one geometry form Relay serves. A resource’s primary geometry is exposed as a single CRS84 Point, in exact longitude then latitude order, as an RFC 7946 Feature for a single record and a FeatureCollection for a collection. Spatial search is limited to one declared inclusive point-within-bounding-box predicate over a bbox parameter, and the geometry is subject to the selected disclosure profile like any other property. Registry Stack product term.

evidence offering: Metadata entry in a Registry Manifest dataset that describes a verification capability and the access path a client uses to reach it, published under the schema versions registry-manifest-evidence-offering/v1 and registry-manifest-evidence-offerings/v1. Registry Manifest compiles and publishes offerings. An offering is a pointer; the service that publishes it does not evaluate the capability behind it. Relay serves no evidence offering and reports the evidence capability family as unsupported.

static discovery bundle: Manifest-generated directory containing catalog.json, dcat.jsonld, cpsv-ap.jsonld, shacl.jsonld, entity and form JSON Schemas, OGC Records item collections, evidence offering JSON, policy JSON-LD, and embedded SKOS-shaped codelist metadata in linked-data outputs. Can be hosted as static files without running a runtime service. Distinct from a Relay sealed package, which is one deployment’s own governed startup input. 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.

deployment project: The directory an Evidence Gateway 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. Evidence Gateway publishes its signing keys at GET /.well-known/evidence/jwks.json and Registry Mint publishes its own at a configured path, default /.well-known/jwks.json. Both are served without authentication so a verifier can obtain the public key without holding a credential.

authoring project: The mutable directory an adopter edits for one Relay deployment: a governed contract, the reviewed source schema observations, and the fixture cases that prove them, which relayctl compiles and seals into one Relay package. relay never serves an authoring project, only the sealed package built from it. A project describes exactly one Relay deployment and spans no other product; an Evidence Gateway deployment is authored separately as a deployment project. Registry Stack product term.

trust domain: The institutional boundary whose operators, runtime identities, policy, and deployment approval govern one authoring project. A geographic jurisdiction can contain several trust domains, and a trust domain does not need to represent a country. One Relay process serves one sealed package inside one trust domain, and one Evidence Gateway serving process serves exactly one operator-controlled trust domain. Registry Stack product term.

source: For Relay, one SQLite database declared in the governed contract, read through the shared bounded read-only boundary over the views the contract names, under exactly one source profile. An identity issuer’s discovery or JSON Web Key Set endpoint is not a source. Evidence Gateway uses the same word for its own configured provider, whose origin, method, path, headers, authentication, transport trust, timeout, and byte limits are fixed in the bundle and executed only by the Rust core. Registry Stack product term.

deployment: An operated set of Relay or Evidence Gateway product instances. Each product verifies and activates its own configuration; there is no cross-product activation coordinator, and this is not atomic project activation. For Relay, a governed change is a new sealed package and a new process, never a live reload. Registry Stack product term.

issuer mode: Removed Registry Relay signed response credentials configuration axis. Registry Relay no longer signs under a gateway DID or a delegated ministry DID, and no current stack service exposes an issuer-mode configuration axis. 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. Evidence Gateway maps its assertion payload onto CCCEV terms under the frozen mapping products/evidence/contracts/cccev-field-mapping.yaml, with named Evidence Gateway extensions where CCCEV has no counterpart.

SHACL: Shapes Constraint Language. W3C recommendation. Registry Manifest emits SHACL node shapes for entity validation, and Relay generates a SHACL shape per resource and per access profile into its sealed package.

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 and policy render output. Relay generates a vocabulary document and a context document per resource and access profile, and negotiates application/ld+json for records.

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.

GeoJSON: RFC 7946 geographic JSON. Relay serves a disclosed primary geometry under application/geo+json in the Point profile. It offers no general geospatial query language, no tiles, and no environmental data retrieval surface.

JSON-FG: OGC Features and Geometries JSON. The formatProfile query parameter selects between rfc7946 and jsonfg, where jsonfg adds the JSON-FG Core and Types-Schemas identifiers and a governed feature type to the same Point wire format. Relay implements no extended JSON-FG geometry and no generic feature API.

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.

SDMX: Statistical Data and Metadata eXchange. Relay serves the SDMX read profile over the statistical datasets a governed contract declares, in the pinned exchange versions application/vnd.sdmx.data+json;version=2.1.0, application/vnd.sdmx.data+csv;version=2.1.0, and application/vnd.sdmx.structure+json;version=2.1.0, aligned to SDMX REST 2.2.2. Relay claims no full SDMX conformance and no certification, and it is not an SDMX registry.

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

PDP: Policy decision point. Relay 1.0 used a shared Registry Platform primitive to evaluate governed policy against trusted request and source context. That runtime and its registry-platform-pdp crate are retired and removed. Registry Manifest retains descriptive PDP-gate and ODRL vocabulary, but no maintained runtime evaluates it. Evidence Gateway has never used a PDP because its authorization is one decision over the verified token, the requirement, and the matched grant. Registry Stack product term.

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.

ODRL enforcement profile: Registry Stack product term for the Open Digital Rights Language (ODRL) term vocabulary a governed evidence pack declares. The identifier is registry-evidence-gateway-pdp/v1, a legacy Relay name that does not name or connect to the Evidence Gateway product. Registry Manifest validates the identifier and the supported term list; the Relay 1.0 runtime that once enforced odrl:purpose under it is retired.

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: Commitment that every exchange the stack mediates is authorized, scoped, and audited. Concretely: caller verification against exactly one configured OIDC issuer; scope-checked operations; disclosure limited to what an access profile, a disclosure profile, or a requirement declares in advance; no source-registry data mutation through any runtime; audit envelopes for every request that touches person-level data, written before the response is released. Registry Stack product term.

executable safeguards: Runtime-enforced safeguards: scoped operations, compiled disclosure profiles, fail-closed audit events, machine-readable metadata, and other enforcement behavior that can be checked by software rather than taken on trust. 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 evaluated against purpose limitation as part of its authorization decision. In Relay, purpose is contract-declared on the access profile and never caller-asserted: a request carrying a Purpose or X-Purpose header is refused. In Evidence Gateway, purpose is a configured code drawn from the requirement and the caller’s grant. 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: Commitment that every promise the stack makes is backed by an artifact a third party can inspect without trusting the operator’s word. Examples include the DCAT and ODRL metadata Registry Manifest renders, a Relay sealed package and the SHACL shapes, JSON Schemas, and OpenAPI documents a reader can re-derive from it, the audit envelope schema, the JWKS public key endpoint, and the Evidence Gateway security invariant matrix with its test traceability. Registry Stack product term.

interoperability: Commitment that what each product publishes is standards-shaped rather than deployment-specific, so downstream systems integrate against stable contracts. A Relay deployment generates OpenAPI, JSON Schema, SHACL, and SDMX projections from its own reviewed contract. Registry Manifest renders portable metadata in DCAT, BRegDCAT-AP, CPSV-AP, CCCEV, ODRL, OGC Records, SKOS-shaped codelist, GeoJSON, and JSON-FG shapes. Evidence Gateway serializes SD-JWT VC under its frozen profile. 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 the registry-consultation slice of a DPI deployment.

Retired vocabulary

Version 0.12.0 removed the terms that named only the retired Relay 1.0 runtime or its adopter tooling, because no maintained component implements them and this specification is verified. From the governed runtime path: governed Relay PDP profile, PEP, trust context, route identity, checked scope, PDP audit provenance, and stable PDP denial code. From the gateway surface: entity route, crosswalk, measures, observations, OGC API Features, OGC API EDR, and SP DCI. From project authoring: integration, entity, service, records service, service policy, output, environment, and deployment bundle. Registry Stack project is retired with them: it named the single authored root registryctl compiled into inputs for several products at once, and nothing replaced that root, so a Relay deployment is authored as an authoring project that spans no other product. Archived docsets keep the definitions as published, and the retirement decision record records why the runtime behind them is retired rather than revised.

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: the portable metadata layer (Registry Manifest and the static discovery bundle).
• consultation: Relay’s read-only record operations and the contract that compiles them.
• evaluation: Evidence Gateway requirement evaluation and assertion issuance.
• credential: retired. It named a retired product’s credential issuance, direct and over OID4VCI; no current page should declare it.
• federation: retired. It named a retired product’s delegated (static-peer) evaluation; no current page should declare it.
• administration: operator administration surfaces, including configuration and the key and reload boundaries.
• operations: runtime operation and recovery, including audit sinks, deployment, 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 friendlier reference form of this vocabulary and the source these definitions distill. RS-TERMS is authoritative where the two disagree.
• The standards register records each external standard mapped in Section 3, with its adoption mode and the products that use it.
• The architecture specification RS-ARC-G is the referent for the layer vocabulary in Section 6: each layer names a component or surface defined there.
• The Relay packaging, access, disclosure, and Registry Core terms in Section 3 are stated normatively in RS-PR-RELAY, the relayctl terms in RS-PR-RELAYCTL, and the Relay authoring guide is the key-by-key reference for the governed contract and the deployment binding.
• The Evidence Gateway terms in Section 2 are distilled from the frozen Version 1 contracts under products/evidence/contracts/ and are stated normatively in RS-PR-EVIDENCE.

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.