Standards register

View as Markdown

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.

Registry Relay 1.0 support roster

Registry Relay’s 1.0 compatibility promise covers the stable surfaces in this roster. Experimental surfaces are outside that promise and feature-frozen: maintainers keep their source and tests, but do not expand them without a separately reviewed support decision. Non-feature-gated experimental formats remain shipped and unstable because adding a gate for 1.0 would break existing configurations.

The stable link-free OGC Records metadata artifacts are separate from the experimental live OGC API Records adapter. CSV, XLSX, and Parquet are source decoders. Aggregate output supports JSON, CSV, and SDMX-JSON, with only JSON stable for 1.0.

Surface	Category	Support owner	Delivery	Evidence
OpenAPI 3.x publication	`standard`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/openapi/registry-relay.openapi.json`
RFC 9457 problem contract	`standard`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/error_taxonomy.rs`
RFC 9727 API catalog	`standard`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/e2e_health.rs`
DCAT and DCAT-AP metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
BRegDCAT-AP metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
JSON-LD metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
SHACL metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
JSON Schema metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
ODRL policy metadata	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
Link-free OGC Records metadata artifacts	`portable_metadata`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/catalog_entity.rs`
CSV source input	`source_decoder`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/format_csv.rs`
XLSX source input	`source_decoder`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/format_xlsx.rs`
JSON aggregate output	`aggregate_output`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/aggregates_entity.rs`
Attribute release	`adapter`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/tests/attribute_release_api.rs`
Crosswalk runtime	`runtime`	`registry-relay`	Canonical 1.0 release	`crates/registry-relay/src/attribute_release/mod.rs`

Experimental and feature-frozen

Surface	Category	Cargo feature	Delivery	Evidence
Live OGC API Records adapter	`adapter`	`ogcapi-records`	Source available; excluded from the canonical release	`crates/registry-relay/tests/ogc_records_api.rs`
OGC API Features	`adapter`	`ogcapi-features`	Source available; excluded from the canonical release	`crates/registry-relay/tests/ogc_api.rs`
OGC API Environmental Data Retrieval	`adapter`	`ogcapi-edr`	Source available; excluded from the canonical release	`crates/registry-relay/tests/ogc_edr_api.rs`
SP DCI sync routes	`adapter`	`spdci-api-standards`	Source available; excluded from the canonical release	`crates/registry-relay/tests/spdci_api_standards.rs`
Standards-CEL mapping	`adapter`	`standards-cel-mapping`	Source available; excluded from the canonical release	`crates/registry-relay/tests/spdci_config_validation.rs`
SDMX-JSON aggregate output	`aggregate_output`	Compiled in; not feature-gated	Shipped, unstable, and frozen	`crates/registry-relay/tests/aggregates_entity.rs`
CSV aggregate output	`aggregate_output`	Compiled in; not feature-gated	Shipped, unstable, and frozen	`crates/registry-relay/tests/aggregates_entity.rs`
Parquet source input	`source_decoder`	Compiled in; not feature-gated	Shipped, unstable, and frozen	`crates/registry-relay/tests/format_parquet.rs`

Generated from src/data/relay-support.yaml. Every decision is dated2026-07-19 and referencesRegistry Stack issue #305.

Register

DCAT and DCAT-AP

dcat

Status: used· 2026-06-13
Claim level: emits
Adoption mode: profiled
Used by: registry-relay registry-manifest
Surface: metadata rendering catalog JSON-LD access service metadata

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

Status: used· 2026-06-13
Claim level: emits
Adoption mode: profiled
Used by: registry-relay registry-manifest
Surface: business registry catalog metadata embedded SHACL entity shapes

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

Status: used· 2026-05-25
Claim level: emits
Adoption mode: profiled
Used by: registry-manifest
Surface: public service catalogue rendering channel and form linking competent authority and requirement links

CPSV-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-records

Status: used· 2026-07-19
Claim level: emits
Adoption mode: profiled
Used by: registry-relay registry-manifest
Surface: dataset catalogue discovery OGC records item bodies

OGC API Records (no numbered spec version asserted; URL-pinned)

The link-free Records metadata artifacts are stable for 1.0. The live Relay adapter behind ogcapi-records is a separate experimental, feature-frozen surface outside the 1.0 compatibility promise. Manifest renders and publishes static OGC Records item collections.

OGC API Features

ogc-api-features

Status: used· 2026-07-19
Claim level: emits
Adoption mode: profiled
Used by: registry-relay
Surface: feature collection discovery dataset-scoped feature items

OGC API Features (no numbered spec version asserted; URL-pinned)

Relay exposes OGC API Features routes behind the ogcapi-features feature. The adapter is experimental, feature-frozen, and outside the 1.0 compatibility promise. 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

Status: used· 2026-07-19
Claim level: emits
Adoption mode: profiled
Used by: registry-relay
Surface: area queries over configured spatial aggregates EDR collection discovery

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 adapter is experimental, feature-frozen, and outside the 1.0 compatibility promise. The claim is scoped to the tested adapter surface, not full OGC conformance.

OpenAPI

openapi

Status: used· 2026-07-19
Claim level: emits
Adoption mode: adopted
Used by: registry-relay registry-notary
Surface: generated API reference native OpenAPI publication

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

Status: used· 2026-06-13
Claim level: emits
Adoption mode: adopted
Used by: registry-relay registry-manifest
Surface: validation workflow entity node shapes

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

Status: used· 2026-06-20
Claim level: emits
Adoption mode: profiled
Used by: registry-manifest
Surface: embedded codelist concept schemes SHACL field codelist bindings BRegDCAT/DCAT dataset codelist references

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

Status: used· 2026-06-13
Claim level: emits
Adoption mode: adopted
Used by: registry-relay registry-manifest
Surface: entity schema documents static discovery bundle

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

Status: used· 2026-06-13
Claim level: emits
Adoption mode: adopted
Used by: registry-relay registry-manifest registry-notary
Surface: catalog JSON-LD CPSV-AP service catalogue JSON-LD policy JSON-LD CCCEV render output

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

Status: used· 2026-06-13
Claim level: emits
Adoption mode: profiled
Used by: registry-notary registry-platform
Surface: credential issuance selective disclosure contracts shared SD-JWT VC issuance and holder-proof helpers

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, issuer signing with EdDSA over Ed25519 or ES256 over P-256, and EdDSA `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

Status: referenced· 2026-05-23
Claim level: aligns_with
Adoption mode: not adopted
Used by: registry-notary
Surface: credential issuance positioning SD-JWT VC credential issuance

Verifiable 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

cccev

Status: used· 2026-05-25
Claim level: emits
Adoption mode: profiled
Used by: registry-manifest registry-notary
Surface: requirement and information requirement metadata evidence type and evidence type list metadata grouped evidence option discovery claim result rendering evidence node JSON-LD

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

Status: used· 2026-07-09
Claim level: emits
Adoption mode: adopted
Used by: registry-relay registry-manifest registry-platform
Surface: dataset-scoped offers policy documents governed evidence PDP constraint terms

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. 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

sdmx

Status: used· 2026-07-19
Claim level: emits
Adoption mode: profiled
Used by: registry-relay
Surface: aggregate data output content negotiation delivery

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. This aggregate representation remains shipped but is experimental, feature-frozen, and outside the 1.0 compatibility promise.

PROV-O

prov-o

Status: referenced· 2026-05-23
Claim level: inspired_by
Adoption mode: not adopted
Used by: registry-notary
Surface: provenance model discussion provenance-shaped claim fields

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.

HL7 FHIR

fhir-r4

Status: used· 2026-07-09
Claim level: maps_to
Adoption mode: profiled
Used by: registry-relay
Surface: product-neutral Relay script adaptation bounded FHIR R4 search-set parsing helper

FHIR 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-registries

Status: evaluated· 2026-05-23
Claim level: compares_against
Adoption mode: not adopted
Used by: registry-relay
Surface: product positioning capability boundary

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

Status: evaluated· 2026-06-15
Claim level: compares_against
Adoption mode: not adopted
Used by: registry-relay registry-manifest registry-notary
Surface: Framework 2.0 principle and pathway comparison technical alignment positioning

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

Status: referenced· 2026-07-19
Claim level: maps_to
Adoption mode: adapted
Used by: registry-relay
Surface: optional sync adapter authored Relay source integration

Optional 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`. The adapter and standards-CEL mapping are experimental, feature-frozen, and outside the 1.0 compatibility promise. 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

oid4vci

Status: used· 2026-07-19
Claim level: emits
Adoption mode: profiled
Used by: registry-notary registry-platform
Surface: issuer-initiated offer start and authenticated callback pre-authorized token endpoint with transaction-bound proof nonce credential issuance endpoint SD-JWT VC Type Metadata issuer metadata at `/.well-known/openid-credential-issuer` registry-backed holder-wallet issuance

Profiled issuer subset using `dc+sd-jwt`, issuer-initiated pre-authorized code, and `openid4vci.support: not_full_issuer`

Registry Notary exposes a registry-backed, issuer-initiated pre-authorized code flow. The identity provider's authorization code is an internal Notary input and not a wallet grant. Metadata advertises `dc+sd-jwt`, EdDSA `did:jwk` holder proof, and the configured EdDSA or ES256 issuer algorithm. Transaction code is required by default; an explicit no-PIN profile has a maximum 300-second bearer-offer window. Source-free claims cannot authorize issuance. The profile makes no claim for a public nonce endpoint, response next nonce, wallet-facing authorization code, ES256 holder proof, EUDI, HAIP, PAR, DPoP, or wallet attestation. Source tests cover the full issuance and client-verification journey. External wallet, verifier, and OpenID conformance evidence remains candidate-only until captured from a frozen release artifact.

W3C Decentralized Identifiers (DID Core)

w3c-did

Status: used· 2026-06-13
Claim level: emits
Adoption mode: profiled
Used by: registry-notary registry-platform
Surface: did:jwk parsing for credential subjects issuer identifier handling shared DID validation and Ed25519 JWK helpers

DID 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

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.

Claim levels, strongest to weakest: implements (a normative requirement or API
shape from the standard), emits (artifacts shaped like the standard, such as
JSON-LD, SHACL, or OpenAPI), maps_to (local concepts or fields mapped to the
standard), aligns_with (follows the model or intent without claiming formal
conformance), inspired_by (the standard influenced design but no compatibility
is claimed), and 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_by or compares_against: design context only, no interoperability claim.

Column guide

Standard links to the official standards body page.
Status is one of used, referenced, evaluated, planned, or historical.
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.

Gaps

OGC API Features and OGC API EDR are listed as profiled emits claims 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.