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
dcat DCAT 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-ap BRegDCAT-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-ap CPSV-AP 3.2.0
Registry Manifest emits CPSV-AP service catalogues. Registry Lab demonstrates the static metadata flow. Registry Relay does not expose a current CPSV-AP runtime route.
OGC API Records
ogc-api-records OGC 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-features OGC 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-edr OGC 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
openapi OpenAPI 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
shacl SHACL 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
skos SKOS 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-schema Draft 2020-12
Manifest renders entity JSON Schemas (the pinned fixture declares Draft 2020-12) and Relay exposes entity schema endpoints.
JSON-LD
json-ld JSON-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-vc Profiled 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-credentials Verifiable Credentials Data Model 2.0
Relay has VC-oriented provenance fixtures and contexts, and Notary issues SD-JWT VC. Keep this below an emits claim until a reviewed VC profile and validation fixtures are pinned.
Core Criterion and Core Evidence Vocabulary
cccev CCCEV 2.2.0
Manifest emits CCCEV requirement and evidence type list metadata. Notary renders CCCEV-shaped claim results. Profile conformance is not claimed.
ODRL
odrl ODRL 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. Separately, Relay's governed Evidence Gateway runtime path can select a governed-evidence binding and call the shared PDP using the `registry-evidence-gateway-pdp/v1` profile; the implemented runtime enforcement terms are currently `odrl:purpose` and `odrl:spatial`, while unsupported ODRL terms are denied rather than treated as enforced.
SDMX-JSON
sdmx SDMX-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-o PROV-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.
GovStack Digital Registries Building Block
govstack-digital-registries Digital 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-safeguards Universal 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-dci Optional sync adapter and source connector (no SP-DCI spec version asserted; URL-pinned)
Relay exposes an SP-DCI sync adapter behind `spdci-api-standards`. Notary ships an HTTP source connector that maps SP-DCI search and sync responses into claim evaluation inputs.
OpenID for Verifiable Credential Issuance
oid4vci OID4VCI 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 hosted lab issuer metadata advertises `format: dc+sd-jwt` for the citizen credential configuration. Registry Platform owns the underlying primitives in the `registry-platform-oid4vci` crate. Registry Lab exercises the full flow through the `just citizen-oid4vci-*` recipes. 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 against the lab smoke script.
W3C Decentralized Identifiers (DID Core)
w3c-did DID Core 1.0 with did:web and did:jwk methods
Relay publishes a did:web document, Notary parses did:jwk values for credential subjects, and Platform owns shared DID and Ed25519 JWK helpers. 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:web and 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 Relay has VC-oriented provenance fixtures and Registry Notary issues SD-JWT VC credentials, but neither project emits a full W3C VC Data Model envelope. Promote when a reviewed VC profile and validation fixtures are pinned. - 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.