Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/v/0.38.0/llms.txt
Full corpus: https://docs.registrystack.org/v/0.38.0/llms-full.txt

# Standards register

> Standards referenced by the registry stack, with explicit claim levels and supporting evidence.

import StandardsTable from '../../../components/StandardsTable.astro';

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](../itb-semic-evidence/).

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

Relay aligns with the [SDMX REST 2.2.2](https://github.com/sdmx-twg/sdmx-rest/tree/v2.2.2),
[SDMX-JSON 2.1.0](https://github.com/sdmx-twg/sdmx-json/tree/v2.1.0), and
[SDMX-CSV 2.1.0](https://github.com/sdmx-twg/sdmx-csv/tree/v2.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](https://json.sdmx.org/2.1.0/). 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`](https://github.com/registrystack/registry-stack/tree/v0.20.0/products/relay-v2/acceptance/labour-statistics).

## Register

<StandardsTable />

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

{/* SVG diagram. Essential labels are restated in the list above. */}
<figure>
  <img src="../../images/standards-claim-levels.svg"
       alt="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)." />
</figure>

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_by` or `compares_against`: design context only, no interoperability claim.

{/* A claim is only as strong as its evidence. When evidence is a README sentence, the claim is at most aligns_with. When evidence is a test, fixture, or generated artifact, the claim can reach emits or implements. A standard appears in the register only when it has all required fields. */}

## 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 covered by the displayed claim level.
- **Claim level** uses the six levels defined in [Claim levels](#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

- 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_against` with 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](#relay-spatial-wire-format-profile), which makes no OGC API conformance claim. OGC API Records
  stays at `emits` because Registry Manifest still publishes static Records item collections; only
  Relay's live Records adapter went with V1. See
  [Relay V1 and registryctl retirement](../../decisions/relay-v1-and-registryctl-retirement-2026-08-11/).
- 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_against` with 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-pdp` crate was
  removed; Registry Manifest retains the descriptive vocabulary it validates.
- The CCCEV row's `emits` claim applies to Registry Manifest. Evidence Gateway separately
  [`maps_to` CCCEV fields](https://github.com/registrystack/registry-stack/blob/v0.21.0/products/evidence/contracts/cccev-field-mapping.yaml)
  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.
  {/* Confirmed absence: no `prov:` namespace or PROV-O `@context` found in Relay source at reviewed commits. PROV-O influences the design (audit fields, claim provenance struct) but no PROV-O vocabulary is emitted. Keep at inspired_by. */}