Standards register
This register lists every standard the registry stack touches, the projects that touch it, and the claim level that names how strong the relationship is. The registry stack does not introduce a new standard; each project emits, maps to, or aligns with existing ones, and says so explicitly.
The table is generated from src/data/standards.yaml.
For selected external validator results, see ITB and SEMIC evidence.
Register
Section titled “Register”DCAT and DCAT-AP
dcatDCAT 3 plus DCAT-AP profile usage
Relay and Manifest emit DCAT-shaped metadata; the emitted catalog structure is asserted by Relay's catalog tests. Profile conformance claims still require profile-specific validation evidence (no DCAT validator output is pinned).
BRegDCAT-AP
bregdcat-apBRegDCAT-AP 2.00 render surface
Manifest and Relay emit BRegDCAT-shaped registry and data-service metadata; the `/metadata/dcat/bregdcat-ap` route output is asserted by Relay's catalog tests. CPSV-AP is now the service-discovery layer; BRegDCAT-AP remains the registry and data-service discovery layer. Later BRegDCAT-AP releases require a separate renderer review.
Core Public Service Vocabulary Application Profile
cpsv-apCPSV-AP 3.2.0
Registry Manifest emits CPSV-AP service catalogues. Registry Relay does not expose a current CPSV-AP runtime route.
OGC API Records
ogc-api-recordsOGC API Records (no numbered spec version asserted; URL-pinned)
Relay exposes records routes behind the ogcapi-records feature (route output asserted by the OGC records API tests), and Manifest renders and publishes static OGC Records item collections.
OGC API Features
ogc-api-featuresOGC API Features (no numbered spec version asserted; URL-pinned)
Relay exposes OGC API Features routes behind the ogcapi-features feature. The claim is scoped to the profiled route output tested in Registry Relay, not full OGC conformance.
OGC API Environmental Data Retrieval
ogc-api-edrOGC API EDR (no numbered spec version asserted; URL-pinned)
Relay exposes OGC API EDR area routes behind the ogcapi-edr feature for configured spatial aggregates. The claim is scoped to the tested adapter surface, not full OGC conformance.
OpenAPI
openapiOpenAPI 3.x
Relay and Notary generate OpenAPI; the pinned generated documents are cited directly. These docs publish the same pinned artifacts as native API reference pages.
SHACL
shaclSHACL Core
Relay emits SHACL/JSON-LD documents whose structure is asserted by its catalog tests, and Manifest renders SHACL. No SHACL validator run against the emitted shapes is pinned.
Simple Knowledge Organization System
skosSKOS Reference codelist concept-scheme profile
Registry Manifest emits flat SKOS-shaped `skos:ConceptScheme` and `skos:Concept` nodes for manifest codelists inside SHACL and BRegDCAT/DCAT-shaped outputs. It does not yet publish a standalone SKOS artifact or claim full SKOS conformance.
JSON Schema
json-schemaDraft 2020-12
Manifest renders entity JSON Schemas (the pinned fixture declares Draft 2020-12) and Relay exposes entity schema endpoints.
JSON-LD
json-ldJSON-LD 1.1
The projects emit JSON-LD artifacts and contexts; a pinned JSON-LD fixture is cited as a concrete emitted artifact. No broad RDF dataset conformance claim is made here.
SD-JWT VC
sd-jwt-vcProfiled subset using the `application/dc+sd-jwt` media type and `dc+sd-jwt` JWT `typ` (no specific IETF draft revision pinned by the implementation)
Registry Platform owns reusable SD-JWT VC issuance and holder-proof helpers. Registry Notary owns the claim-to-credential workflow and service routes that use them. The profile is constrained: `application/dc+sd-jwt` credentials, EdDSA over Ed25519, `did:jwk` holder binding. Pre-rename format aliases such as `application/vc+sd-jwt` are rejected in operator configuration. Full SD-JWT VC conformance is not claimed.
Verifiable Credentials Data Model
verifiable-credentialsVerifiable Credentials Data Model 2.0
Registry Notary issues SD-JWT VC. Relay no longer emits or hosts VC artifacts.
Core Criterion and Core Evidence Vocabulary
cccevCCCEV 2.2.0
Manifest emits CCCEV requirement and evidence type list metadata. Notary renders CCCEV-shaped claim results. Profile conformance is not claimed.
ODRL
odrlODRL Information Model 2.2; emitted policies use ODRL Vocabulary terms
Relay catalog JSON-LD can include dataset-scoped ODRL Offers, and Manifest renders ODRL policy metadata. That publication surface is descriptive and is not itself an access grant. The shared governed Evidence Gateway profile vocabulary includes `odrl:purpose` and `odrl:spatial`, but Relay's governed runtime path currently enforces `odrl:purpose` only; `odrl:spatial` and other unsupported ODRL terms are denied fail-closed rather than treated as enforced.
SDMX-JSON
sdmxSDMX-JSON 2.1 data messages
Relay serves configured aggregates as SDMX-JSON 2.1 data messages via content negotiation (application/vnd.sdmx.data+json;version=2.1) or ?f=sdmx-json. Scope is data messages only: structure messages and the SDMX REST API are not implemented. Relay-specific x-extensions carry unit, multiplier, decimals, and completeness metadata; measure definition URIs are not mapped; the message sender is fixed. Conformance evidence is the Relay test suite validating output against the published SDMX-JSON data-message schema.
PROV-O
prov-oPROV-O
The code uses provenance concepts, but current evidence does not show a PROV-O vocabulary emission surface. Keep this as design influence until PROV-O terms are emitted or mapped.
HL7 FHIR
fhir-r4FHIR R4 bounded Relay script-helper profile
Registry Relay exposes a bounded FHIR R4 search-set parser to product-neutral Rhai scripts. Project code owns profile-specific matching and projections. Source product and version metadata do not enable the helper, and Registry Stack does not claim to implement a FHIR server or broad FHIR conformance.
GovStack Digital Registries Building Block
govstack-digital-registriesDigital Registries Building Block (no numbered spec version asserted; URL-pinned)
Relay explores a protected consultation gateway model rather than the current single uniform CRUD platform.
Universal DPI Safeguards Framework
universal-dpi-safeguardsUniversal DPI Safeguards Framework version 2.0 (governance framework; no numbered technical specification asserted)
The framework is a governance instrument, not a technical specification, so no conformance is claimed. The alignment page compares stack capabilities against selected Framework 2.0 principles and pathways at the technical implementation layer and states explicitly that alignment is not certification.
Social Protection Digital Convergence Initiative
sp-dciOptional Relay sync adapter and authored source integration (no SP-DCI spec version asserted; URL-pinned)
Relay exposes an SP-DCI sync adapter behind `spdci-api-standards`. A Registry Stack project can also compile a reviewed DCI source journey into a Relay consultation. Registry Notary consumes the consultation result and does not connect to DCI sources directly.
OpenID for Verifiable Credential Issuance
oid4vciOID4VCI Draft 13, profiled issuer subset (SD-JWT VC `dc+sd-jwt` format; advertised as `openid4vci.support: not_full_issuer`)
Registry Notary exposes the OID4VCI credential offer, nonce, credential, and issuer-metadata routes as a profiled subset of OID4VCI Draft 13. The historical v0.9.0 Registry Lab issuer metadata advertised `format: dc+sd-jwt` for the citizen credential configuration. Registry Platform owns the underlying primitives in the `registry-platform-oid4vci` crate. The historical Registry Lab exercised the flow through the `just citizen-oid4vci-*` recipes at v0.9.0. Solmara Lab checks the current hosted issuer metadata, credential offer, nonce, authorization redirect, and unauthenticated denial paths through `just hosted-smoke`. Full OID4VCI issuer conformance is not asserted: the server advertises itself as `openid4vci.support: not_full_issuer`, and the surfaces emit the protocol shape validated by the checked smoke paths.
W3C Decentralized Identifiers (DID Core)
w3c-didDID Core 1.0 with did:web and did:jwk methods
Notary parses did:jwk values for credential subjects, and Platform owns shared DID and Ed25519 JWK helpers. Relay no longer hosts a did:web document. No DID resolver, DID URL dereferencing, or DID Core conformance class is implemented, so the claim stays at emits. The site does not claim conformance to the wider DID method registry beyond did:jwk.
Generated from src/data/standards.yaml.
Claim levels
Section titled “Claim levels”Six levels in descending strength:
implements: the project implements a normative requirement or API shape from the standard.emits: the project produces artifacts shaped like the standard (JSON-LD, SHACL, OpenAPI, catalog records).maps_to: local concepts or fields are mapped to the standard.aligns_with: the project follows the model or intent without claiming formal conformance.inspired_by: the standard influenced design without any compatibility claim.compares_against: the standard is discussed to explain boundaries or alternatives.
What these levels mean for integrators:
emits: you can parse that project’s output as the standard expects. Fixtures or generated artifacts back the claim.aligns_with: the project uses the vocabulary and intent of the standard but does not guarantee strict conformance. Do not write a validator against the spec without reading the surface notes.implements: a normative requirement is met; you can rely on the API shape.inspired_byorcompares_against: design context only, no interoperability claim.
Column guide
Section titled “Column guide”- Standard links to the official standards body page.
- Status is one of
used,referenced,evaluated,planned, orhistorical. - Used by lists the registry stack projects that reference this standard.
- Claim level uses the six levels defined above.
- Surface names the specific output or endpoint that the claim applies to.
- Profile and notes identifies the version or profile in use and any boundary conditions.
- Evidence links to the source code, fixture, or document that supports the claim.
- OGC API Features and OGC API EDR are listed as profiled
emitsclaims for Registry Relay. The claims are scoped to the tested feature-gated adapter routes, not full OGC conformance. - The Verifiable Credentials Data Model (W3C VC) is listed as
aligns_with(referenced). Registry Notary issues SD-JWT VC credentials, but it does not emit a full W3C VC Data Model envelope. Registry Relay no longer emits or hosts VC artifacts. - PROV-O is listed as
inspired_by(referenced). The code uses provenance-shaped concepts (audit fields, claim provenance struct) but no PROV-O vocabulary terms are emitted as JSON-LD.