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
Section titled “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 Evidence Gateway 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 self-attestation and clarified direct self-attestation. |
| 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 self-attestation terminology with RS-PR-NOTARY. |
| 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 Notary source connectors and sidecars with compiler-pinned Relay consultations and Registry Stack project authoring terms. |
| 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. |
1. Products
Section titled “1. Products”The registry stack comprises four formal products. Product names are Title Case. Repository slugs appear in monospace and are always lowercase. The phrase “registry stack” (lowercase) refers to the four-product ensemble.
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 both runtime services.
Registry Relay (registry-relay): Config-driven Rust service that owns registry source access, product-neutral HTTP and script adaptation, immutable snapshot lookup, and protected, read-only consultation APIs.
Registry Manifest (registry-manifest): Rust workspace for modeling, validating, and rendering standards-facing service, registry, form, and policy metadata without running Registry Relay. Provides a library (registry-manifest-core) and a command-line interface (registry-manifest-cli).
Registry Notary (registry-notary): Standalone Rust service for Relay-backed or self-attested claim evaluation, disclosure policy, credential issuance from exact Relay-backed evaluation provenance, and audit. Source-free claims are evaluation-only. It has no direct registry source connector.
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. Protocol and credential terms
Section titled “2. Protocol and credential terms”claim evaluation: The Registry Notary process that evaluates configured evidence rules over compiler-pinned Relay outputs or permitted self-attestation and returns a structured claim result. Registry Stack product term.
evidence claim: A verifiable claim, attestation, credential claim, or status assertion that Registry Notary evaluates from Relay outputs or permitted self-attestation. Registry Stack product term.
disclosure profile: Registry Notary control over what the caller receives from a claim evaluation result: value (full value disclosed), predicate (only true/false satisfaction), or redacted (value fully hidden). Registry Stack product term.
holder: The party that holds a credential in a wallet and presents it to a verifier. Registry Notary binds each credential to a holder key (did:jwk) in the cnf claim, so only the holder can present it.
wallet: A holder-owned application that stores credentials and presents them to verifiers. Registry Notary issues credentials; the wallet that stores, unlocks, and presents them is a separate component owned by the holder.
self-attestation: Registry Notary access pattern where an authenticated OIDC principal is the protected requester for configured claim evaluation. Registry Notary has two self-attestation access modes: self_attestation (direct self-attestation), where the authenticated principal is the subject, and delegated_attestation (delegated self-attestation), where the authenticated principal is the requester and a configured dependent target can be evaluated only when scoped authorization details name the same target, relationship, and proof claim. Source-free and delegated claims are evaluation-only. Subject access can authorize credential issuance only for non-delegated registry-backed evidence. Registry Stack product term.
delegated self-attestation: Registry Notary self-attestation access mode delegated_attestation. The requester is derived from the authenticated principal, the request target and scoped authorization details identify the same configured dependent subject, the relationship is derived from scoped authorization details, and the dependent claim can continue only after the compiler-pinned Relay proof consultation evaluates to boolean true. This is distinct from static-peer delegated evaluation under Notary federation. Registry Stack product term.
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. Use Registry Notary for credential issuance.
SD-JWT VC: Selective Disclosure JWT Verifiable Credential (IETF draft). Registry Notary issues registry-backed SD-JWT VC credentials signed with EdDSA or ES256. OID4VCI holder proof remains EdDSA with did:jwk binding. Media type: application/dc+sd-jwt.
OID4VCI: OpenID for Verifiable Credential Issuance. Registry Notary implements a profiled registry-backed issuer subset with dc+sd-jwt, an issuer-initiated pre-authorized code, a transaction-bound proof nonce returned by the token response, and EdDSA did:jwk holder proof. The identity provider’s authorization code is an internal Notary input, not a wallet grant. The profile has no public nonce endpoint, response next nonce, source-free issuance, ES256 holder proof, EUDI, HAIP, PAR, DPoP, or wallet-attestation claim. Full issuer and external-wallet conformance are not asserted (openid4vci.support: not_full_issuer).
DID: Decentralized Identifier. W3C DID Core 1.0. Registry Relay no longer publishes a DID document. Registry Notary parses did:jwk values for credential subjects.
eSignet: Open-source identity and authentication service (part of MOSIP). Registry Notary can use eSignet for the internal browser authentication leg of a registry-backed pre-authorized credential transaction. Its authorization code is consumed by Notary and is not a wallet grant. Not a Registry Stack product term.
3. Metadata and standards terms
Section titled “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 Registry Relay runtime bindings such as source paths, table names, or scopes. Registry Stack product term.
runtime binding: Registry Relay configuration that connects logical manifest concepts to actual files, database tables, scopes, and backend credentials. Lives in Relay config, not in the manifest. Registry Stack product term.
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 Registry Relay. 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.
entity route: A Registry Relay API route shaped around a domain resource such as household or individual, not around storage table identifiers. Registry Stack product term.
crosswalk: The Registry Relay feature that maps source field names and values to canonical domain terms using configured CEL expressions. Replaces the former cel-mapping name. Enabled by the crosswalk-runtime Cargo feature and the standards-cel-mapping feature alias. Config key: crosswalk. Registry Stack product term.
measures: The configured numeric computations in a Registry Relay aggregate definition (renamed from indicators). Each measure has an id, a label, an aggregation method (count, sum, average, among others), and a source column. Returned in the AggregateResult.measures field alongside observations. Registry Stack product term.
observations: The array of data rows returned in the AggregateResult.observations field for a Registry Relay aggregate query. Each observation is an object keyed by dimension and measure identifiers. Replaces the former data field name from the SDMX-refactor rename. Registry Stack product term.
evidence offering: Metadata entry that describes a verification capability and the access path a client uses to reach it. In the current stack it points a client from Registry Relay metadata to Registry Notary or another evidence service; Relay describes the offering but does not evaluate the claim. 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.
claim definition: The Registry Notary configuration artifact that declares a named claim capability: its identity, evidence mode, typed inputs, compiler-pinned Relay consultations where registry-backed, the single rule that decides its value, and the disclosure, format, and credential rules that shape what leaves the service. Registry Stack product term.
credential profile: Registry Notary configuration that names which claims may be issued as a credential. A Registry Stack project authors this membership once on the profile; the compiler derives the claim-to-profile reverse index required by Registry Notary’s product configuration. 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. Registry Notary owns issuer configuration for credentials.
JWKS: JSON Web Key Set. Registry Notary publishes its issuer’s public verification keys at GET /.well-known/evidence/jwks.json, served without authentication so a verifier can obtain the public key without holding a Notary credential.
Relay consultation: A compiler-pinned request from Registry Notary to Registry Relay. The binding names a Relay profile id and contract hash, maps only declared typed request inputs, and requires purpose agreement before Relay performs source work. Registry Stack product term.
Registry Stack project: The authored root for one registry trust domain. It can describe a Relay-only, Notary-only, or combined deployment, and compiles separate product configuration inputs for the selected topology. Registry Stack product term.
trust domain: The institutional boundary whose operators, runtime identities, policy, and deployment approval govern one Registry Stack project. A geographic jurisdiction can contain several trust domains, and a trust domain does not need to represent a country. Registry Stack product term.
source: The one logical registry data interface available to Registry Relay, when present, inside the project trust domain. An OAuth or JSON Web Key Set endpoint used by a protocol is not another data source. Registry Stack product term.
integration: A reusable Registry Relay-owned unit that accepts typed inputs, uses http,
script, or snapshot against the project source, and returns a consultation outcome plus
declared outputs. Product and version metadata do not select its capability. Registry Stack
product term.
entity: A logical Registry Relay-local schema that can be materialized and queried by
snapshot and can optionally be exposed through a records service. Registry Stack product term.
service: An authored, purpose-bound public capability. Use the specific term evidence service or records service when the distinction matters. A service is not a Registry Relay or Registry Notary process. Registry Stack product term.
evidence service: A Registry Notary-owned service containing service policy, claims, disclosure, optional Registry Relay consultations, and optional credential profiles. Registry Stack product term.
records service: A Registry Relay-owned records API exposure of an entity, with its own access, purpose, projection, filter, and pagination policy. Registry Stack product term.
service policy: The purpose, legal basis, consent, caller access, and disclosure rules governing one service. Registry Stack product term.
consultation: A named use of one Registry Relay integration by an evidence service. One consultation can supply several Registry Notary claims. Registry Stack product term.
output: A typed, minimized scalar returned by Registry Relay on a matching consultation. Registry Stack product term.
claim: A Registry Notary-owned, purpose-specific value or predicate derived from consultation outcome and outputs. Registry Stack product term.
environment: Private bindings and operational settings for one Registry Stack project deployment target, without changing stable project intent. Registry Stack product term.
deployment bundle: The generated, signed artifact for one Registry Stack project and environment. Its root manifest binds compatible Registry Relay and Registry Notary submanifests when both are present. The current authoring command emits unsigned product inputs rather than a deployment bundle; signed project-root bundles are deferred. Registry Stack product term.
deployment: One activated deployment-bundle generation. Replicas of that generation are one logical deployment. Registry Stack product term.
static-peer federation: Registry Notary delegated evaluation between peers loaded from configuration at startup; a request from an unconfigured peer is rejected. A configured peer posts a compact signed JWT request through POST /federation/v1/evaluations and receives a compact signed JWT response carrying a scoped evaluation result. Dynamic trust-chain discovery and federated credential issuance are out of scope. Registry Stack product term.
DCAT: Data Catalog Vocabulary. W3C recommendation. Registry Relay and Registry Manifest emit DCAT-shaped JSON-LD catalogs. Spell out on first use per document.
BRegDCAT-AP: SEMIC profile of DCAT-AP for base registries. Registry Relay and Registry Manifest emit 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 Notary renders CCCEV-shaped JSON-LD for claim evaluation results. Media type: application/ld+json; profile="cccev".
SHACL: Shapes Constraint Language. W3C recommendation. Registry Relay and Registry Manifest emit SHACL node shapes for entity validation.
ODRL: Open Digital Rights Language. W3C recommendation. Registry Relay and Registry Manifest emit ODRL Offer documents for dataset-scoped descriptive policies. Governed Evidence Gateway runtime enforcement uses only the supported ODRL enforcement terms declared by the registry-evidence-gateway-pdp/v1 profile; publishing an ODRL policy document is not itself runtime enforcement.
JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Used for catalog, policy, and CCCEV render output.
OGC API Records: Open Geospatial Consortium API specification for records. Registry Relay exposes records endpoints behind the ogcapi-records feature flag. Registry Manifest renders and publishes an OGC Records item collection.
OGC API Features: Open Geospatial Consortium API specification for feature collections and items. Registry Relay exposes a profiled feature collection surface behind the ogcapi-features feature flag.
OGC API EDR: Open Geospatial Consortium API specification for Environmental Data Retrieval. Registry Relay exposes profiled area queries over configured spatial aggregates behind the ogcapi-edr feature flag.
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.
SP DCI: Social Protection Digital Convergence Initiative. Registry Relay exposes an SP DCI adapter behind the spdci-api-standards feature flag and can execute a reviewed DCI source integration. Registry Notary consumes the resulting Relay consultation.
SDMX: Statistical Data and Metadata eXchange. Registry Relay serves configured aggregates as SDMX-JSON 2.1 data messages (media type application/vnd.sdmx.data+json;version=2.1) through content negotiation or ?f=sdmx-json. Scope is limited to data messages: structure messages and the SDMX REST API are not implemented.
PROV-O: W3C Provenance Ontology. Currently listed as design influence (inspired_by). Provenance-shaped concepts appear in audit fields and the claim provenance struct, 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
Section titled “4. Governance and safeguards terms”Evidence Gateway: Registry Stack product term for the governed runtime path that selects an evidence pack or claim policy and asks the shared PDP to permit, redact, or deny a Relay read, Relay consultation, or Notary claim evaluation. The metadata manifest describes governed evidence bindings and evidence packs; runtime services perform the PDP enforcement for their configured surfaces.
PDP: Policy decision point. In Registry Stack, the shared Registry Platform primitive that evaluates a governed policy against trusted request and source context and returns permit, permit with redaction, or deny with stable pdp.* provenance. Registry Stack product term.
PEP: Policy enforcement point. The runtime service surface, such as a Registry Relay governed read or consultation, or a Registry Notary claim evaluation, that calls the PDP and enforces the resulting permit, redaction, or deny decision. Registry Stack product term.
governed evidence: Evidence metadata and runtime behavior bound to a governed evidence ecosystem binding (type: governed-evidence). In the 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. At runtime, Relay can use the selected binding to feed the PDP policy id, policy hash, supported ODRL terms, source freshness, route identity, source binding, checked scope, and trust context into a decision.
ecosystem binding: Manifest-level binding that connects an external ecosystem profile or governed evidence pack to a Registry Stack runtime surface. A governed evidence ecosystem binding names the evidence-pack metadata and policy identity a runtime service can use for PDP enforcement. Registry Stack product term.
ODRL enforcement profile: Registry Stack product term for the governed Evidence Gateway profile vocabulary for Open Digital Rights Language (ODRL) terms. The current profile is registry-evidence-gateway-pdp/v1; the profile vocabulary includes odrl:purpose and odrl:spatial, but runtime services can support a subset. Registry Relay currently enforces odrl:purpose and denies odrl:spatial fail-closed.
PDP gate: A named policy decision point check evaluated by the shared Registry PDP, such as policy identity, ODRL terms, purpose, jurisdiction, assurance, source freshness, legal basis, consent, requested disclosure, source binding, route identity, checked scope, and redaction. PDP gates produce evaluated rule IDs in audit records.
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; Relay records the selected PDP policy hash in governed audit provenance.
trust context: Trusted facts supplied to the PDP for a governed decision. The context can include the authenticated principal, checked scopes, requested purpose, route identity, source binding, requested fact or disclosure, jurisdiction, assurance, legal basis, consent, and source freshness. Caller-supplied facts count only when backed by trusted assertion scopes or trusted source metadata. Registry Stack product term.
source binding: Runtime or source-policy identifier that names the configured source service, resource, or claim binding a governed decision is allowed to use. Source binding lets audit records and PDP rules distinguish one backend source from another. Registry Stack product term.
route identity: Canonical identifier for the runtime route or claim path being evaluated by the PDP. Route identity prevents a policy written for one route from silently authorizing another route with a similar shape. Registry Stack product term.
checked scope: Authorization scope that the runtime service has already verified before PDP enforcement and then passes into the PDP and audit provenance. A PDP decision MUST NOT invent a checked scope that ordinary authorization did not verify. Registry Stack product term.
PDP audit provenance: Audit fields that explain a governed PDP decision, including policy id, policy hash, evaluated rule ids, route identity, source binding, checked scopes, trust-provenance labels, and stable pdp.* denial code when denied. Registry Stack product term.
safeguards: Commitment that every exchange the stack mediates is authorized, scoped, and audited. Concretely: authentication by API key or OIDC; scope-checked routes; per-claim disclosure control (value, predicate, or redacted); no source-registry data mutation through Relay; audit envelopes for every request that touches person-level data. Registry Stack product term.
executable safeguards: Runtime-enforced safeguards: scoped routes, disclosure policy, audit events, machine-readable metadata, and other policy enforcement point behavior that can be checked by software. 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 that carries or is evaluated against purpose limitation, policy-based access control, or context-aware authorization. Registry Relay records the Data-Purpose header in audit records where present. Registry Stack product term.
source freshness: PDP gate that compares trusted source metadata or trusted source-observation context against a configured maximum age. A failure produces a stable PDP denial code such as pdp.evidence_stale.
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 published DCAT catalog, the SHACL shapes, the ODRL policy documents, the audit envelope schema, the JWKS public key endpoint, and the credential profile configuration. Registry Stack product term.
interoperability: Commitment that every registry in the stack publishes its catalog, schemas, services, and policies in standards-shaped form (DCAT, BRegDCAT-AP, CPSV-AP, CCCEV, SHACL, JSON Schema, ODRL, OpenAPI, OGC Records, SKOS-shaped codelists, SD-JWT VC), so downstream systems integrate against stable contracts rather than per-deployment ones. Registry Stack product term.
stable PDP denial code: A machine-stable pdp.* problem code returned on governed PDP denials and recorded in audit provenance as pdp_stable_problem_code. Examples include pdp.purpose_not_permitted, pdp.evidence_stale, pdp.legal_basis_required, pdp.jurisdiction_not_permitted, pdp.unsupported_policy_term, and pdp.policy_hash_invalid.
fail closed: Security posture where missing, malformed, unsupported, stale, or unauditable governed policy inputs result in denial rather than permit. 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.
5. Abbreviations
Section titled “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 |
| DCAT | Data Catalog Vocabulary |
| DID | Decentralized Identifier |
| DPI | Digital Public Infrastructure |
| JSON-LD | JSON Linked Data |
| JWKS | JSON Web Key Set |
| ODRL | Open Digital Rights Language |
| OID4VCI | OpenID for Verifiable Credential Issuance |
| OGC API EDR | OGC API Environmental Data Retrieval |
| OGC API Features | Open Geospatial Consortium API - Features |
| OGC API Records | Open Geospatial Consortium API - Records |
| PDP | Policy Decision Point |
| PEP | Policy Enforcement Point |
| PROV-O | W3C Provenance Ontology |
| SD-JWT VC | Selective Disclosure JWT Verifiable Credential |
| SHACL | Shapes Constraint Language |
| SKOS | Simple Knowledge Organization System |
| SP DCI | Social Protection Digital Convergence Initiative |
| SDMX | Statistical Data and Metadata eXchange |
6. Documentation declaration terms
Section titled “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: Registry Relay’s protected, read-only consultation APIs.
- evaluation: Registry Notary claim evaluation.
- credential: Registry Notary credential issuance, direct and over OID4VCI.
- federation: Registry Notary delegated (static-peer) evaluation.
- 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
Section titled “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.
- 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.