Standards register
This register lists every standard Registry Stack touches and the projects that touch it. It records
each relationship using one of six explicit claim levels: implements, emits, maps_to,
aligns_with, inspired_by, or compares_against. Registry Stack does not introduce a new
standard.
The table is generated from src/data/standards.yaml.
For selected external validator results, see ITB and SEMIC evidence.
Relay spatial wire-format profile
Section titled “Relay spatial wire-format profile”Relay uses GeoJSON and JSON-FG as optional wire formats for the same governed Registry Record.
The profile is one classified Point in CRS84, with an exact bounded bbox query on a
separately named consultation.search operation. The operation’s access profile remains the
authorization and maximum-disclosure boundary. This does not claim Open Geospatial Consortium API
Features support.
Relay SDMX read profile
Section titled “Relay SDMX read profile”Relay aligns with the SDMX REST 2.2.2,
SDMX-JSON 2.1.0, and
SDMX-CSV 2.1.0 primary specifications through a
governed read subset over pre-aggregated snapshots. This is an aligns_with claim, not a
conformance, compatibility, or certification claim.
The subset contains these GET routes:
/sdmx/v2/data/dataflow/{agencyID}/{resourceID}/{version}/{key}/sdmx/v2/data/dataflow/{agencyID}/{resourceID}/{version}, with the omitted key equivalent to*/sdmx/v2/structure/dataflow/{agencyID}/{resourceID}/{version}/sdmx/v2/structure/datastructure/{agencyID}/{resourceID}/{version}
Data responses use application/vnd.sdmx.data+json;version=2.1.0 or
application/vnd.sdmx.data+csv;version=2.1.0. Structure responses use
application/vnd.sdmx.structure+json;version=2.1.0 and the
official 2.1.0 schemas. The profile exposes no schema or
availability placeholders, other structure types, maintenance routes, or dynamic aggregation.
Each statistical dataset has one fixed access rule and does not accept the Record-oriented
accessProfile request parameter. The complete synthetic project and its expected HTTP exchanges
are tracked at
products/relay-v2/acceptance/labour-statistics.
Register
Section titled “Register”DCAT and DCAT-AP
dcatDCAT 3 plus DCAT-AP profile usage
Registry Manifest emits DCAT-shaped metadata. The DCAT catalog route belonged to the retired Relay V1 runtime and the pinned V1 catalog tests are the record of it; the contract-compiled Relay serves no catalog route and emits no DCAT document. Profile conformance claims still require profile-specific validation evidence (no DCAT validator output is pinned).
BRegDCAT-AP
bregdcat-apBRegDCAT-AP 2.00 render surface
Registry Manifest emits BRegDCAT-shaped registry and data-service metadata. The `/metadata/dcat/bregdcat-ap` route belonged to the retired Relay V1 runtime and the pinned V1 tests are the record of it; the contract-compiled Relay serves no such route. 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)
Registry Manifest renders and publishes static OGC Records item collections, and those link-free Records metadata artifacts are stable for 1.0. The live Records adapter was a feature-gated surface on the retired Relay V1 runtime and the pinned V1 tests are the record of it; the contract-compiled Relay serves no OGC API route.
OGC API Features
ogc-api-featuresOGC API Features (no numbered spec version asserted; URL-pinned)
No maintained Registry Stack surface implements OGC API Features. The feature-gated routes belonged to the retired Relay V1 runtime and the pinned V1 tests are the record of them. The contract-compiled Relay names OGC API Features an intentional gap. Its spatial surface is the CRS84 Point profile serialized as GeoJSON and JSON-FG on a governed operation, which is a wire format and not a feature service.
OGC API Environmental Data Retrieval
ogc-api-edrOGC API EDR (no numbered spec version asserted; URL-pinned)
No maintained Registry Stack surface implements OGC API EDR. The area routes belonged to the retired Relay V1 runtime and the pinned V1 tests are the record of them. The contract-compiled Relay names EDR an intentional gap and offers no area query, no coordinate transformation, and no generic spatial database API.
GeoJSON
geojsonRFC 7946 Point, Feature, and FeatureCollection profile
Relay V2 emits RFC 7946 Point Features and FeatureCollections only when the selected access profile discloses the primary geometry. The profile uses exact CRS84 longitude-latitude coordinates and does not claim an OGC API Features service.
OGC Features and Geometries JSON
json-fgJSON-FG 1.0 Core and Types-Schemas profile over an RFC 7946 Point
Relay V2 adds the JSON-FG Core and Types-Schemas identifiers plus a governed feature type to the same Point wire format. It does not implement extended JSON-FG geometries or a generic feature API.
OpenAPI
openapiOpenAPI 3.1.0; Relay generated per deployment, Evidence services fixed generated contracts
Relay compiles two OpenAPI 3.1.0 projections from each deployment's own registry contract and seals both into the package, an operator-only full document and the public subset it serves at `GET /openapi.json`. There is no product-level Relay OpenAPI document to pin because deployments with different contracts can describe different surfaces; fetch the document from the deployment. Evidence Gateway and its separate OID4VCI supporting service each generate a fixed OpenAPI 3.1.0 contract. The Registry Notary link stays pinned as the record of a retired product, not as a surface an adopter can run.
SHACL
shaclSHACL Core
Relay generates SHACL Core shapes in Turtle per operation and access profile from a compiled contract, seals them into the package, and serves them at `GET /v2/artifacts/{artifactIdentifier}` under the contract's metadata visibility. Manifest renders SHACL from a manifest. 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). Relay generates Draft 2020-12 schemas from a compiled contract, one operator-only full record schema per resource plus one schema per operation and access profile. It seals them into the package and serves them at `GET /v2/artifacts/{artifactIdentifier}` under the contract's metadata visibility, so a deployment that publishes its semantics answers anonymously and one that binds them to an operation requires a credential.
JSON-LD
json-ldJSON-LD 1.1
Relay generates a JSON-LD 1.1 context and vocabulary from a compiled contract and can also serve a JSON-LD representation of a governed response. Manifest renders JSON-LD artifacts, and a pinned fixture is cited as a concrete emitted artifact. No broad RDF dataset conformance claim is made here.
OpenID for Verifiable Credential Issuance
oid4vciOpenID for Verifiable Credential Issuance 1.0 Final, frozen Registry pre-authorized-code profile
The separate `registry-evidence-oid4vci` supporting service implements a frozen subset of OID4VCI 1.0 Final for holder-bound Evidence credentials. The profile permits issuer-initiated anonymous pre-authorized-code delivery, a stateless nonce, ES256 JWT proofs with an inline public JWK or self-contained `did:jwk#0`, and plural `dc+sd-jwt` credentials. It excludes authorization code, PAR, DPoP, remote DID resolution, other credential formats, deferred issuance, notifications, status or revocation, persistence, and multiple replicas. This is a profile implementation claim, not full issuer certification or conformance. Exact pinned source-level interoperability and the sanitized Registry flow passed. This is not OpenID certification, device or UI evidence, compatibility with other revisions, or general Inji compatibility.
SD-JWT VC
sd-jwt-vcRFC 9901 and `draft-ietf-oauth-sd-jwt-vc-18`, under the frozen Evidence audience-scoped and holder-bound profiles
Registry Platform owns reusable SD-JWT VC issuance and holder-proof helpers. Evidence Gateway serializes its stateless assertion as an SD-JWT VC under its own frozen profile, and that profile is the source of truth for the claim set it emits. Two subject binding modes exist. Under the default audience-scoped mode the credential is meaningful only to the relying party the assertion names, and a caller-supplied holder key is echoed into `cnf` unverified. Under the declared holder-bound mode the binding derives from the RFC 7638 thumbprint of the holder key, `cnf` is required, and possession is proven at presentation by a key-binding JWT under RFC 9901 section 4.3 rather than by the audience at issuance. Verifying a key-binding JWT proves possession at signing time over the presented bytes; comparing its nonce is not consuming it, so nothing here is replay prevention. Both profiles and the strict verification policy are frozen and citable. Evidence signs issuer JWTs with ES256 over P-256. Evidence confirmation keys, RFC 9901 key-binding JWTs, and OID4VCI proofs use ES256 over P-256. Registry Platform also retains a generic EdDSA holder-proof helper, but that is not the Evidence holder-bound presentation path. Registry Notary is retired; its pinned conformance profile and format constants remain historical evidence. Full SD-JWT VC conformance is not claimed. Wallet-facing OID4VCI delivery belongs to the separate `registry-evidence-oid4vci` front end.
Verifiable Credentials Data Model
verifiable-credentialsVerifiable Credentials Data Model 2.0
Evidence emits and the OID4VCI service transports an IETF draft-18 SD-JWT VC. That format is not a W3C Verifiable Credentials Data Model 2.0 document. No maintained component emits a W3C VCDM 2.0 envelope. The retired Notary alignment remains historical evidence only.
Core Criterion and Core Evidence Vocabulary
cccevCCCEV 2.2.0
Manifest emits CCCEV requirement and evidence type list metadata. The pinned Notary renderer and media type constants record the CCCEV-shaped claim results of a retired product. Profile conformance is not claimed.
ODRL
odrlODRL Information Model 2.2; emitted policies use ODRL Vocabulary terms
Registry Manifest renders ODRL policy metadata. That publication surface is descriptive and is not itself an access grant. Dataset-scoped ODRL Offers in catalog JSON-LD and the governed PDP evaluation path belonged to the retired Relay V1 runtime, and the contract-compiled Relay emits no ODRL document and evaluates no ODRL constraint, because its authorization boundary is the compiled access profile. The retired `registry-platform-pdp` crate is removed; Registry Manifest retains the enforcement profile vocabulary, including `odrl:purpose` and `odrl:spatial`, as descriptive metadata, so nothing in the stack enforces an ODRL term today. The technical identifier remains `registry-evidence-gateway-pdp/v1` for compatibility and does not name the Evidence Gateway product.
Statistical Data and Metadata eXchange (SDMX)
sdmxREST 2.2.2 read subset; SDMX-JSON and SDMX-CSV 2.1.0
Relay defines a read profile over governed, pre-aggregated snapshots: keyed or omitted-key dataflow data plus dataflow and data structure definition reads. Data JSON, data CSV, and structure JSON use version 2.1.0. The profile has one fixed dataset access rule, not Record access profiles, and omits schema and availability placeholders, other structure types, maintenance routes, and dynamic aggregation. It claims no full SDMX conformance or certification. The retired Relay V1 runtime served a different and unrelated surface, experimental SDMX-JSON 2.1 data messages through aggregate content negotiation, and it implemented no SDMX REST route.
PROV-O
prov-oPROV-O
The pinned claim model belongs to Registry Notary, which is retired. Provenance concepts shaped that model, but no PROV-O vocabulary emission surface was shown then and no service in this register claims one now. Keep this as design influence until PROV-O terms are emitted or mapped.
HL7 FHIR
fhir-r4FHIR R4 (no profile implemented)
No maintained Registry Stack surface parses or serves FHIR. The bounded R4 search-set parser was exposed to Rhai scripts by the retired Relay V1 runtime, and the pinned helper and authoring fixture are the record of it. The contract-compiled Relay runs no script and reads only local read-only SQLite sources with no outbound request, so a FHIR server is not a source it reaches. Evidence Gateway's frozen fixed-source contract accepts `application/json`, not `application/fhir+json`, so FHIR compatibility runs through a local read-through adapter the operator writes, which requests and validates FHIR JSON and exposes the bounded result as ordinary JSON. That adapter and its profile-specific matching are project code, not a Registry Stack surface. Registry Stack has never claimed 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 a single uniform CRUD platform. A registry contract may declare GovStack as an alignment target, but the compiler accepts that declaration only when its status is `directional`, and it stays descriptive metadata echoed back on the service document. It binds no vocabulary, compiles no route, and is not a conformance claim.
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-dciSP-DCI (no spec version asserted; URL-pinned)
No maintained Registry Stack surface speaks SP-DCI. The sync adapter behind `spdci-api-standards`, its standards mapping, and the authored DCI source journey all belonged to the retired Relay V1 runtime and its tooling, and the pinned fixture is the record of them. The contract-compiled Relay reads only local read-only SQLite sources and makes no outbound source request, so it connects to no DCI source.
W3C Decentralized Identifiers (DID Core)
w3c-didDID Core 1.0 boundary around self-contained did:jwk
Registry Relay no longer publishes did:web. The OID4VCI supporting service accepts a self-contained did:jwk#0 proof-key reference, decodes it locally as an ES256 P-256 public key, and never performs remote resolution. Platform retains shared DID and JWK helpers, while the pinned Notary route is historical. No current service publishes a DID document or operates a general DID resolver, and no DID Core conformance class is claimed.
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: the named output is shaped according to the stated standard or profile. Read the row’s notes and evidence before assuming validator conformance.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: only the named normative requirement or API surface, within the stated profile and evidence boundary, is implemented.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 covered by the displayed claim level.
- Claim level uses the six levels defined in Claim levels.
- 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.
Scope boundaries
Section titled “Scope boundaries”- OGC API Features and OGC API EDR were feature-gated routes on the retired Relay V1 runtime, and no
maintained surface implements them. Both are recorded at
compares_againstwith no user, and their pinned V1 tests are kept as the record of a surface that no longer ships. Relay’s current spatial surface is the CRS84 Point profile described in Relay spatial wire-format profile, which makes no OGC API conformance claim. OGC API Records stays atemitsbecause Registry Manifest still publishes static Records item collections; only Relay’s live Records adapter went with V1. See Relay V1 and registryctl retirement. - HL7 FHIR R4 and SP-DCI were reachable only through the retired V1 source model, which read remote
sources over HTTP and let project scripts adapt them. The current Relay reads one local read-only
SQLite file and makes no outbound source request, so both standards are recorded at
compares_againstwith no user. - ODRL is still emitted by Registry Manifest as policy metadata, and that metadata is descriptive
rather than an access grant. No maintained runtime enforces an ODRL constraint. The governed
evaluation path belonged to Relay V1. Its
registry-platform-pdpcrate was removed; Registry Manifest retains the descriptive vocabulary it validates. - The CCCEV row’s
emitsclaim applies to Registry Manifest. Evidence Gateway separatelymaps_toCCCEV fields under its frozen assertion profile and does not emit a CCCEV document. - Evidence Gateway emits an IETF SD-JWT VC under its frozen draft-18 profile, and the separate OID4VCI supporting service transports it. This is not a W3C Verifiable Credentials Data Model 2.0 envelope. No maintained component emits a W3C VCDM 2.0 document; Relay does not emit or host one.
- 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.