Glossary

View as Markdown

Use this page to look up unfamiliar terms. Product names are always in English, including on future translated pages.

acceptance definition: One complete authored answer path in an Evidence Gateway deployment project: a source with its request and response schema, the extraction script, the fact schema and any codelist, the derivation, the requirement with its concept and disclosure guard, the authority grant that permits it, and the synthetic fixture cases that prove it before anything is served. Evidence Gateway Version 1 freezes four coequal acceptance definitions: adult status, residence region, professional licence status, and legal-parent relationship. None is privileged in the runtime, so there is no domain type, built-in operation, or special route for any of them.
access profile: A named pairing of one access rule and one disclosure profile on a Registry Relay resource. The access rule is either public or a protected rule naming the required scope and, optionally, a purpose constraint and an authority row binding. A caller selects a profile with the accessProfile request parameter, and the profile it selects is both the authorization decision and the maximum disclosure the response may carry: no parameter, header, or token claim widens it. Statistical datasets carry one fixed access rule instead and do not accept the parameter. Declared in registry.yaml (crates/registry-relay-v2/src/contract.rs).
access token: The bearer credential a caller presents to Evidence Gateway. Evidence Gateway runs one authentication kind, oidc-access-token, whose issuer, audiences, accepted token types, algorithms, JWKS URI, and claim names are fixed in the immutable bundle, and it reads authority only from those configured claim names. Registry Mint issues such tokens for deployments with no identity provider. Any issuer may be used only when it satisfies that complete configured token profile and signs with a key accepted from the configured JWKS; matching claim names alone is insufficient.
assertion: Evidence Gateway’s output: one stateless signed payload that answers a requirement and carries no source record. Its member set is closed by products/evidence/contracts/evidence.schema.yaml: the requirement it supports, the Evidence Type it conforms to, issuer and provider, issue, observation, and validity instants, purpose, audience, configuration revision, role-bound subject bindings, and the supported values. A holder-bound assertion carries neither audience nor request nonce, because it names no relying party to echo them to. Signed flattened JSON Web Signature (JWS) is the default serialization; the SD-JWT VC serialization carries the same assertion and adds no credential lifecycle.
BRegDCAT-AP: SEMIC profile of DCAT-AP for base registries. Registry Manifest emits BRegDCAT-AP-shaped registry and data-service metadata. Registry Relay emits no DCAT-family document.
authoring project: The local directory an adopter writes for one Registry Relay deployment: registry.yaml, runtime.yaml, reviewed governance documents, codelists, and fixture inputs. relayctl init writes a starter project, relayctl check compiles it, relayctl generate writes its reviewable artifacts, and relayctl package seals it. The project is the reviewed input; the sealed package is what an operator deploys. See the relayctl command reference.
CCCEV: Core Criterion and Core Evidence Vocabulary. Registry Manifest emits CCCEV-shaped requirement, evidence type, and evidence type list metadata. Evidence Gateway maps its assertion payload onto CCCEV terms under the frozen mapping in products/evidence/contracts/cccev-field-mapping.yaml, with named Evidence Gateway extensions where CCCEV has no counterpart.
caller: The technical client that invokes Registry Relay or Evidence Gateway. A caller can be the evidence consumer or an intermediary, portal, or workflow connector acting for it.
claim level: The evidence discipline these docs use for standards claims: implements, emits, maps_to, aligns_with, inspired_by, or compares_against.
consultation: Registry Relay’s Record-oriented read surface: the operations that answer a question about governed Registry Records, as against the SDMX statistical surface. One consultation follows one of three patterns, list, retrieve, or search. Consultation-specific refusals use consultation.invalid_request, consultation.denied, consultation.unresolved, consultation.response_too_large, or consultation.rate_limited. Shared request, authentication, resource, format, source, audit, service, and internal failures retain their own code families. Consultations belong to Relay and are not an Evidence Gateway source contract.
consumer decision: An eligibility, qualification, prioritization, approval, routing, payment, workflow, or other outcome determined outside Registry Relay and Evidence Gateway by or for an evidence consumer. The decision owner remains accountable for its rules and consequences.
DCAT: Data Catalog Vocabulary. W3C recommendation. Registry Manifest emits DCAT-shaped JSON-LD catalogs. Spell out on first use per page: “Data Catalog Vocabulary (DCAT)”.
CPSV-AP: Core Public Service Vocabulary Application Profile. Registry Manifest emits CPSV-AP service catalogue JSON-LD. Registry Relay does not expose a current CPSV-AP runtime metadata route.
CRS84 Point: The one geometry Registry Relay supports: a single point in longitude and latitude order under the CRS84 reference system, classified like any other property and disclosed only when the selected access profile admits it. Relay accepts no other geometry type, no alternative reference system, and no geometry in a request body. Spatial filtering is an exact bounded bbox query on a separately named search operation.
crosswalk: Retired Relay 1.0 feature that mapped source field names and values to canonical domain terms using configured CEL expressions. The current Relay runs no expression language: a source column reaches a response only through a declared property with a reviewed classification, or it does not reach one at all.
disclosure profile: A named property list on a Registry Relay resource, naming exactly which of that resource’s declared properties a response may carry. A disclosure profile grants nothing on its own; an access profile pairs it with an access rule, and the response is the intersection of the two. Because the list is enumerated in registry.yaml rather than derived, adding a source column to a database cannot widen an existing profile.
deployment bundle: A deferred project-root packaging concept tracked by registry-stack issue #361. Current source does not generate, sign, verify, or activate a project-root bundle. Each product instead uses its own product-owned bundle, and no Registry Stack coordinator binds or atomically activates them. Not the same thing as an Evidence Gateway deployment project’s governed bundle, which is one product’s immutable startup input.
deployment: An operated set of Registry Relay or Evidence Gateway product instances. Each product stages and activates its own separately verified configuration; there is no cross-product activation coordinator, and this is not atomic project activation.
deployment project: The directory an Evidence Gateway operator mounts: a runtime.yaml file holding process-local bindings, and a bundle/ directory holding the governed configuration, scripts, schemas, codelists, and fixtures. evidencectl new starts a local authoring workspace from exactly one OpenAPI or SQLite source. OpenAPI mode leaves the source, question, and fixture directories empty for authoring; SQLite mode supplies a complete synthetic starter. Both generate disposable Evidence Gateway keys. evidencectl build compiles that workspace and one explicit target into a new production candidate. Evidence Gateway loads a completed bundle read-only at startup; a new revision is a new deployment, not a live change.
decision owner: The institution accountable for the requirements, rules, decisions, and actions that use evidence. The decision owner can operate the evidence consumer directly or rely on a separate caller or intermediary.
DPI: Digital Public Infrastructure. Shared, interoperable digital systems (identity, payments, data exchange) deployed at population scale to support public service delivery. These projects cover the registry-consultation slice of a DPI deployment.
DID: Decentralized Identifier. W3C DID Core 1.0. 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. No current service publishes a DID document or operates a general DID resolver.
distributed custody: The architectural premise that each authority retains control of its own registry data. The registry stack provides the API surface for lawful exchange between authorities; it does not aggregate data into a central system. Equivalent terms include data sovereignty (Gaia-X, IDS, EU dataspaces vocabulary), subsidiarity (governance literature), and federated custody.
Evidence Gateway (product): The minimum-disclosure assertion service in this monorepo. Crate: crates/registry-evidence; product material: products/evidence/. Given authenticated authority, an authorized purpose, and a predefined requirement, Evidence Gateway serves a signed assertion that answers the requirement, not the source record, plus an SD-JWT VC serialization of that same stateless assertion under a frozen Version 1 profile. The SD-JWT VC format is never a credential lifecycle: no issuance session, holder-binding ceremony, status list, or revocation. Evidence Gateway is a separate greenfield product, not a reduced configuration of anything that came before it.
Evidence Gateway toolset: The four released binaries evidence, evidencectl, mint, and evidence-oid4vci. Releases that include the toolset publish reproducible binaries alongside a cosign-signed SHA256SUMS file. The installer stages and checksum-verifies every binary before replacement begins, attempts to restore the previous four-binary set if replacement fails, and does not itself authenticate SHA256SUMS. Use the tag-frozen release verification procedure for authenticity. evidencectl delegates runtime evaluation, signing, bundle validation, and fixture evaluation to evidence, and reuses the Evidence client and portable verifier for relying-party request preparation and offline response verification. It adds no Evidence Gateway semantics of its own. mint, built from the registry-mint crate, issues the access tokens evidence verifies. evidence-oid4vci is the optional wallet delivery front end and adds no assertion semantics.
evidence consumer: A service or process that uses returned evidence. Examples include a social-protection programme, admissions service, licensing authority, healthcare workflow, lender, insurer, or credential verifier. The evidence consumer, caller, and decision owner can be the same component or separate components.
ecosystem binding: Manifest-level binding that connects an external ecosystem profile or governed evidence pack to a Registry Stack runtime surface. A governed evidence ecosystem binding names the evidence pack metadata and policy identity. It is metadata that Registry Manifest validates and publishes; no maintained runtime in the current release consumes it.
eSignet: Open-source identity and authentication service (part of MOSIP). No current Registry Stack service integrates with it. Evidence Gateway authenticates callers against one configured OIDC issuer and key set named in its immutable bundle, and names no specific identity product.
evidence offering: Metadata entry in a Registry Manifest dataset that describes a verification capability and the access path a client uses to reach it (schema versions registry-manifest-evidence-offering/v1 and registry-manifest-evidence-offerings/v1). Registry Manifest compiles and publishes offerings; an offering is a pointer, and no maintained runtime in the current release serves offerings in its own metadata or evaluates the capability behind one.
evidence type list: CCCEV list of evidence types that satisfy a requirement. In Registry Manifest, one list is one grouped option; multiple lists on the same requirement are alternatives.
executable safeguards: Registry Stack product term for safeguards a runtime enforces rather than a policy document asserts: scope-checked routes, disclosure bounded by a declared profile, an audit event for every request that touches person-level data, and machine-readable metadata a third party can check with software.
governed evidence: Governed evidence metadata bound to a governed-evidence ecosystem binding. Manifest validation requires pack identity, evidence metadata, required PDP gates, allowed outputs, policy id and hash binding, and the legacy registry-evidence-gateway-pdp/v1 ODRL enforcement profile identifier, while some evidence metadata fields remain opaque JSON. The identifier does not name or connect to the Evidence Gateway product, and the runtime that once enforced these gates is retired.
historical docs: Older specs, implementation reviews, or pre-rename documents that remain useful evidence but are not current user guidance.
holder: In Evidence Gateway, the party whose public key a caller supplies in the request’s holderKeys array. Under the audience-scoped binding mode the key is optional and inert: Evidence Gateway echoes it into the SD-JWT VC cnf claim and does nothing else with it, so there is no holder-binding ceremony, no presentation verification, and no key-binding JWT. Under the holder-bound mode at least one key is required and its RFC 7638 thumbprint scopes the subject binding. In both modes the key never reaches authorization, selectors, scripts, source requests, or audit, and no private key member is accepted (products/evidence/contracts/request.schema.yaml, products/evidence/contracts/sd-jwt-vc-profile.yaml).
holder-bound: The second Evidence Gateway subject binding mode, declared by a requirement in the immutable bundle. The subject binding derives from the RFC 7638 thumbprint of the holder key rather than from the audience, cnf is required in the credential, the assertion carries neither audience nor request nonce, and the audience check moves from issuance to presentation, where the relying party verifies a key-binding JWT. The mode narrows its requirement’s response formats to the SD-JWT VC serialization and the holder-bound issuance batch envelope, and refuses the two entity-reference value forms, which take the audience as a derivation input. It accepts cross-verifier correlation through holder key reuse, which the service can neither prevent nor detect (products/evidence/contracts/holder-bound-profile.yaml, frozen).
key-binding JWT: The JWT a holder appends to a presentation, defined by RFC 9901 section 4.3, signed by the private key of the credential’s cnf and covering the presented bytes plus the audience and nonce the relying party chose. Evidence Gateway never appends one; the holder does, and the relying party verifies it with the portable verifier or the evidence verify-presentation command. A verified key-binding JWT proves possession at signing time and nothing more: comparing a nonce is not consuming it, so this is not replay prevention, and RFC 9901 section 7.3 leaves the challenge lifecycle to the relying party.
interoperability: Commitment that what each product publishes is standards-shaped rather than deployment-specific, so downstream systems integrate against stable contracts. A Relay deployment generates OpenAPI, JSON Schema, SHACL, and SDMX projections from its own reviewed contract and can serialize governed records as GeoJSON or JSON-FG. Registry Manifest renders portable metadata in DCAT, BRegDCAT-AP, CPSV-AP, CCCEV, ODRL, OGC Records GeoJSON, and SKOS-shaped codelist forms. Evidence Gateway serializes SD-JWT VC under its frozen profile.
JSON-FG: OGC Features and Geometries JSON. One of the two spatial wire formats a Registry Relay response can take, selected by the formatProfile request parameter beside the RFC 7946 GeoJSON profile. The two formats carry the same governed Registry Record and the same access-profile boundary; the choice is a serialization, not a wider disclosure. Relay makes no OGC API Features conformance claim.
JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Used for catalog and policy render output. A Relay application/ld+json response references a context the deployment’s own Registry contract names, generated per registry rather than shared across deployments.
metadata manifest: Portable metadata.yaml document (schema version registry-manifest/v1) that describes a registry through its catalog and defined collections. The Registry Manifest reference is authoritative for the current top-level keys and field schemas. Must not include Relay runtime bindings such as source paths, table names, or scopes.
measure: The one observed value a Registry Relay statistical dataset reports. Each dataset declares exactly one measure, bound to one source column of a pre-aggregated view. Relay computes no aggregate at request time: the numbers it serves are the numbers the source already holds. See also: observation.
minimized evidence: Registry Stack product term for an evidence response shaped by data minimization, selective disclosure, or verifiable attestation. The response can be narrower than the full source record when the configured use case supports that pattern.
minimum disclosure: Evidence Gateway’s design rule: one response carries the smallest sufficient answer to one requirement, never the source record. The assertion payload is closed and rejects additional properties, subject selector profiles and selector values never appear in it, the output gate admits only the exact declared concept identifiers and value forms, and purpose does not narrow disclosure, so a purpose that justifies a coarser answer needs its own requirement. See RS-PR-EVIDENCE Section 6.
ODRL: Open Digital Rights Language. W3C recommendation. Registry Manifest emits ODRL Offer documents for dataset-scoped descriptive policies. Publishing an ODRL document is a description, not enforcement, and no maintained runtime in the current release evaluates ODRL terms.
observation: One row of a Registry Relay statistical dataset: a value of the dataset’s single measure, located by its dimension values and its time period, optionally carrying declared attributes. Observations are served under the SDMX read profile in SDMX-JSON or SDMX-CSV, never through the Record-oriented consultation surface.
OGC API Records: Open Geospatial Consortium API specification for records. Registry Manifest renders and publishes an OGC Records item collection. Registry Relay serves no OGC API Records route.
OGC API Features: Open Geospatial Consortium API specification for feature collections and items. The profiled feature-collection surface that once carried this name was a feature-gated route on the retired Relay 1.0 runtime. The current Relay serves GeoJSON and JSON-FG representations of its own governed Registry Records and claims no OGC API Features conformance.
OGC API EDR: Open Geospatial Consortium API specification for Environmental Data Retrieval. The profiled area queries that once carried this name were feature-gated routes on the retired Relay 1.0 runtime. No maintained runtime in the current release serves them.
OID4VCI: OpenID for Verifiable Credential Issuance. The historical credential-issuance flow is retired. The current registry-evidence-oid4vci supporting service implements the frozen OID4VCI 1.0 Final profile for holder-bound dc+sd-jwt delivery, with protected offer creation, pre-authorized-code token exchange, nonce, and credential endpoints. Evidence Gateway signs the credential and the adapter transports it; deferred issuance, notification, persistence, and draft-13 compatibility remain outside the profile.
operation: One declared capability on a Registry Relay resource, and the unit an access profile is attached to. A resource declares at most one list and one read, plus any number of named lookup and search operations. Each operation compiles to its own route and its own entry in the deployment’s generated OpenAPI description, and each carries its own stable operation identifier in audit records. An undeclared operation has no route: a resource is reachable only through what its contract names.
package revision: The packageRevision member of a sealed package’s relay-package.json: a digest over the canonical JSON of the manifest without that member. It identifies the exact bytes of one sealed package, so two operators can confirm they run the same reviewed contract. It is an integrity digest, not an authenticity proof; Relay packages are unsigned, and the operator’s own transport and storage are what bind a package to its author.
PROV-O: W3C Provenance Ontology. Currently listed as design influence (inspired_by). Provenance-shaped concepts appear in audit fields, but no PROV-O vocabulary terms are emitted as JSON-LD at reviewed commits.
PDP: Policy decision point. Relay 1.0 used a shared Registry Platform primitive to evaluate governed policy against trusted request and source context. That runtime and its registry-platform-pdp crate are retired and removed. Registry Relay now decides access from the compiled access profiles in its sealed package instead.
PDP gate: A named policy decision point check, such as policy identity, ODRL terms, purpose, jurisdiction, assurance, source freshness, legal basis, consent, and redaction. Registry Manifest still validates the required-gate list a governed evidence pack declares; the gates are metadata that describes an intended enforcement, and no maintained runtime evaluates them.
policy hash: Lowercase sha256: digest that binds a governed evidence policy identity to canonical policy bytes or an externally supplied policy artifact. Registry Manifest verifies it when an inline evidence pack policy object is present.
Protected Registry APIs: Registry Stack runtime pattern for exposing existing registry source data through scoped, read-only HTTP routes with authentication, authorization, metadata, and audit. Registry Relay implements this pattern.
registry stack: The formal stack products: Registry Platform, Registry Relay, Registry Manifest, and Evidence Gateway, with Registry Mint as supporting token issuance. Use lowercase when referring to the concept.
purpose: The authorized reason a caller gives for one Evidence Gateway singular request or request batch. A purpose is a configured code drawn from the requirement’s declared purposes list and from the caller’s grant, never caller-defined prose. It is part of each complete authorization decision, is echoed into each assertion, and does not narrow disclosure. A declared purpose is an authorized selection from the granted set, not an identity-provider attestation.
purpose-bound request: Registry Stack product term for a request that carries or is evaluated against purpose limitation, policy-based access control, or context-aware authorization. In Registry Relay, purpose is a constraint an access profile may place on a token claim: the profile names the claim and the closed set of values that admit the request. Relay reads purpose from the verified token, never from a request header or a caller-supplied string.
scope: The authorization scope a protected Registry Relay access profile requires. Relay verifies the scope against the bearer token before the access profile applies, and the profile grants nothing broader than the disclosure profile it names. A scope is not a disclosure decision on its own.
fail closed: Security posture where a missing, malformed, unsupported, stale, or unauditable input results in refusal rather than a partial answer. Registry Relay applies it at startup as well as per request: a package that fails verification is not activated, and the process does not begin serving.
Solmara Lab: Separately maintained adopter demo for the fictional Republic of Solmara. It runs published Registry Stack images in local and hosted topologies and is not a formal Registry Stack product. Repo slug: solmara-lab.
record context: The four bindings every Registry Relay resource declares so a caller can tell one answer from another over time: the record identifier, the revision identifier, the lifecycle state with the codelist that constrains it, and the recorded-at instant. Record context is required, not optional metadata: a resource cannot be published without it, and it is what lets a consumer say which version of a record it acted on.
Registry Manifest: Portable Rust library and CLI for modeling, validating, and rendering standards-facing service, registry, form, and policy metadata without running Registry Relay. Provides registry-manifest-core and registry-manifest-cli.
Registry Mint: Small supporting service, not a fourth registry stack pattern, that issues short-lived, audience-bound access tokens to registered machine clients using the client_credentials grant, so a resource server such as Evidence Gateway or Registry Relay can require signed tokens without standing up a general-purpose identity provider. private_key_jwt is the client-authentication default; a standard authorization client may explicitly select client_secret_basic or client_secret_post compatibility. The client registry binds each client id to its authentication material and to the authority Registry Mint asserts for it. Registry Mint’s tests drive Evidence Gateway’s authenticator; the dependency runs one way only, and Evidence Gateway does not depend on Registry Mint. Crate: crates/registry-mint; binary: mint.
Registry Platform: Shared Rust crates for registry security and operational primitives, including auth helpers, OIDC verification, audit envelopes, HTTP security, outbound HTTP policy, crypto, SD-JWT VC helpers, and test fixtures. Their APIs are workspace-internal and not published compatibility contracts.
Registry contract: The document an institution authors to describe its own registry: registry.yaml, kind: RegistryContract, apiVersion: relay.registrystack.org/v2alpha1. It names the resources, their properties and classifications, the operations Registry Relay will answer, the access and disclosure profiles that bound each answer, and any statistical datasets. It is a closed shape: an unrecognized key is a parse failure, not an ignored field. Its deployment-local half, runtime.yaml (kind: RelayRuntime), stays separate so the reviewed contract carries no secret and no local path.
Registry Record: The unit Registry Relay serves on its consultation surface: one row of a governed resource, projected through a disclosure profile and carrying its record context. It is not a copy of the source row. A property reaches a Registry Record only when the Registry contract declares it and the selected access profile admits it.
Registry Relay: The governed read service in this monorepo. An institution authors a Registry contract over its own SQLite registry, relayctl compiles and seals it into a package, and the relay binary verifies that package before it serves anything. Relay stores no data of its own, writes nothing back to the source, runs no expression language, and exposes no route the contract did not declare. Crate: crates/registry-relay-v2; binary: relay; repo slug: registry-relay. The config-driven Relay 1.0 runtime, with its HTTP and script source adaptation and its policy decision point path, was retired at v0.19.0.
Registry Stack project: Retired term. It named the single authored root that registryctl compiled into configuration inputs for several products at once. registryctl was retired at v0.19.0 and nothing replaced that root: each product is authored on its own. A Relay deployment is authored as an authoring project and sealed into a package; an Evidence Gateway deployment is authored as a deployment project. There is no cross-product project, compiler, or activation coordinator. See Relay V1 and registryctl retirement.
relayctl: Registry Relay adopter tooling and the relayctl binary. It initializes an authoring project, inspects SQLite structure without reading row values, compiles and validates the project, generates reviewable artifacts, runs offline fixture cases, classifies changes between two project revisions, seals a deployment package, writes editor configuration, and provides a language-server protocol. It serves no request, starts no listener, never starts relay, and defines no product-specific environment-variable configuration. Its fixture runner may use the host’s temporary-directory selection only to materialize internal fixture state. Crate: crates/registry-relayctl. It replaced registryctl at v0.19.0. See the relayctl command reference.
requirement: The predefined, versioned question one Evidence Gateway request names. A requirement is declared in the immutable bundle with its identifier, kind, closed single or search-then-fetch acquisition, authorized purposes, subject roles and selector profiles, reference frameworks, Evidence Type, validity, derivation script, concepts, fixtures, and disclosure guard (products/evidence/contracts/bundle.schema.yaml). Only predefined requirements can be evaluated, and to a caller lacking authorization an unknown identifier is indistinguishable from an unauthorized one. The word is CCCEV’s, adopted for the same idea.
request batch: An Evidence Gateway envelope that asks POST /v1/evidence/batch to evaluate between one and sixteen ordered audience-scoped subject sets for one common requirement and purpose. Each item has its own request nonce and complete subject-role set. The response preserves order and contains either one independently signed flattened JWS or evidence_not_available for each item; any other failure aborts the complete request. This envelope is distinct from the holder-bound issuance batch on POST /v1/evidence, which performs one subject evaluation and emits one credential per holder key.
resource: One governed thing a Registry contract publishes, bound to one named source and one view inside it: the resource carries its semantic class, its declared properties and their classifications, its record context, its disclosure profiles, its access profiles, and the operations that answer questions about it. A resource is the authored intent; the view is storage, and the two are deliberately not the same name.
sealed package: The directory relayctl package produces and the relay binary verifies before it activates anything: the compiled contract, the generated artifacts, the observed source schemas, and a relay-package.json manifest carrying the package format version, the contract revision, the package revision, and a digest for every file. Format version relay.registrystack.org/package/v1alpha3. Relay refuses a package whose format version is not the one that binary was built against, and it refuses one whose recomputed digests do not match. Packages are unsigned: verification proves integrity, not authorship.
source profile: How a Registry Relay source is expected to behave while it is being read, declared per source as snapshot or live-read-only. Under snapshot the database is a fixed artifact published for reading, so a response is reproducible for the life of that snapshot. Under live-read-only the database is the operational registry, still opened read-only through the shared SQLite boundary, so answers move as the registry moves. Neither profile permits a write, and both pin the expected schema fingerprint.
source: A named registry data interface a Registry Relay deployment reads. In the current Relay a source is one SQLite database, opened through the read-only boundary in crates/registry-platform-sqlite under its declared source profile, with its schema fingerprint pinned in the contract. An OAuth or JSON Web Key Set endpoint used by a protocol is not another data source. Evidence Gateway uses the same word for its own configured provider, whose origin, method, path, headers, authentication, transport trust, timeout, and byte limits are fixed in the bundle and executed only by the Rust core.
source-owned decision: A decision already made and owned by an authoritative source system. A registry stack service may disclose that fact only when the requirement and its review documentation identify it as source-owned; no service recomputes the decision or claims ownership of its policy.
statistical dataset: A governed, pre-aggregated dataset a Registry contract publishes on Registry Relay’s SDMX read profile rather than its Record surface. Each dataset declares its dimensions, one required time dimension, exactly one measure, any observation attributes, and one fixed access rule; it does not accept the accessProfile request parameter. Relay performs no aggregation at request time.
registry-manifest/v1: Schema version string for portable metadata manifests.
reviewability: Commitment that every promise the stack makes is backed by an artifact a third party can inspect without trusting the operator’s word. Examples include the DCAT and ODRL metadata Registry Manifest renders, the SHACL shapes and JSON Schemas a Relay package seals, the audit envelope schema, the JWKS public key endpoint, and the Evidence Gateway security invariant matrix with its test traceability.
runtime binding: Deployment-local settings that connect an authored contract to one operated environment: the database file paths, the listener, the token issuer and key set, the audit sink, and secret references. In Registry Relay these live in runtime.yaml, outside the reviewed Registry contract and outside the sealed package, so moving a reviewed contract between environments changes no governed meaning. A secret is referenced as secret:env/<NAME> or secret:file/<name>, where <name> is a single flat lowercase filename, and resolved by relay at startup, never written into the contract.
safeguards: Commitment that every exchange the stack mediates is authorized, bounded, and audited. Concretely, in the current Relay: OIDC bearer authentication with scope-checked access profiles; disclosure limited to the property list the selected profile names in advance; a read-only source boundary that admits no write; and a value-free audit event for every request that touches person-level data.
SD-JWT VC: Selective Disclosure JWT Verifiable Credential (IETF draft). Evidence Gateway serializes the same stateless assertion as an SD-JWT VC under the frozen profile in products/evidence/contracts/sd-jwt-vc-profile.yaml, when the immutable bundle and the one matched grant both permit that response format. Under the default audience-scoped binding mode the credential is meaningful only to the relying party named in the assertion’s audience; a requirement declaring the holder-bound mode narrows its formats to this serialization and the holder-bound issuance batch envelope. Neither is a credential lifecycle, and full SD-JWT VC conformance is not claimed. Media type: application/dc+sd-jwt.
subject binding mode: Which value the binding scope takes inside an Evidence Gateway subject binding. The vocabulary is closed at audience-scoped and holder-bound. Omission has the effective default audience-scoped; no caller input selects the mode. Each mode derives under its own domain constant, so the two cannot collide, and both emit into the one urn:evidence:subject namespace. Because the derivation is an HMAC under a deployment secret, a relying party cannot recompute a binding under either mode and pins the expected bindings from independent trusted state.
signed response credentials: Removed Registry Relay feature that attached a W3C VCDM 2.0 VC-JWT signed credential to entity record and aggregate responses. Registry Relay no longer accepts provenance or entity publicschema credential mapping config, no longer serves /.well-known/did.json, /schemas/{claim_type}/{version}, or /contexts/{vocab}/{version}, and no longer returns application/vc+jwt. No current stack service issues W3C VCDM credentials.
SDMX read profile: Registry Relay’s governed read subset of SDMX REST 2.2.2 over pre-aggregated statistical datasets: three GET routes under /sdmx/v2, one for keyed data, one for unkeyed data, and one structure route whose artefact type is dataflow or datastructure, answered as SDMX-JSON 2.1.0, SDMX-CSV 2.1.0, or Structure JSON 2.1.0. It is an aligns_with claim, not conformance or certification. The profile exposes no schema or availability route, no other structure type, no maintenance route, and no dynamic aggregation. See the standards register.
schema fingerprint: A digest of a source database’s structure, recorded when relayctl inspect reads it and pinned in the Registry contract per source. relay recomputes it when it binds the source and refuses to start when it does not match, and recomputes it again on each readiness check, so a schema that drifts under a running deployment turns GET /ready negative rather than changing answers quietly. The fingerprint covers structure only; no row value contributes to it.
SHACL: Shapes Constraint Language. W3C recommendation. Registry Manifest emits SHACL node shapes for its published entity schemas. Registry Relay generates a full-record shape plus shapes bound to each operation and access-profile combination, so a third party can review what a given surface may disclose without calling the service.
SP DCI: Social Protection Digital Convergence Initiative. The SP DCI adapter and the reviewed DCI source integration were surfaces of the retired Relay 1.0 runtime. No maintained runtime in the current release exposes them.
static discovery bundle: Manifest-generated directory whose digest-bearing index.json inventories catalog.json, dcat.jsonld, cpsv-ap.jsonld, shacl.jsonld, entity and form JSON Schemas, OGC Records item collections, evidence offering JSON, policy JSON-LD, and embedded SKOS-shaped codelist metadata in linked-data outputs. It can be hosted as static files without running Registry Relay.
standards-shaped metadata: Registry Stack product term for machine-readable metadata emitted through formats such as DCAT, CPSV-AP, CCCEV, SHACL, JSON Schema, ODRL, OpenAPI, OGC API Records, and SKOS-shaped codelist metadata.
SKOS: Simple Knowledge Organization System. Registry Manifest currently emits flat SKOS-shaped skos:ConceptScheme and skos:Concept nodes for codelists inside SHACL and BRegDCAT/DCAT-shaped outputs. It does not yet publish a standalone SKOS artifact.
trust domain: The institutional boundary whose operators, runtime identities, policy, and deployment approval govern one authored deployment. A country can contain several trust domains, and a trust domain does not need to represent a country. One Registry Relay serving process serves exactly one sealed package, and one Evidence Gateway serving process serves exactly one operator-controlled trust domain.
wallet: Holder-owned application that stores credentials and presents them to verifiers. The separate registry-evidence-oid4vci supporting service exposes a frozen OID4VCI delivery profile to a wallet, while Evidence Gateway itself integrates with none. Wallet onboarding, wallet attestation, trust-list membership, and holder key generation, holding, escrow, or recovery by a service remain non-goals. The holder-bound profile defines what a relying party verifies when a holder presents a credential; no test in this repository covers a wallet storing or presenting an Evidence Gateway credential.

Style notes

Formal product names (Registry Platform, Registry Relay, Registry Manifest, Registry Mint) and the adopter demo name (Solmara Lab) are always title case. The assertion product’s name is Evidence Gateway, capitalized as a proper noun.
Repo slugs and crate names (registry-platform, registry-relay, registry-manifest, registry-evidence, registry-mint, solmara-lab) are always lowercase and monospace. A retired product’s slug, such as registry-notary where a shipped schema or image name still spells it, follows the same rule.
Binary names (relay, relayctl, evidence, evidencectl, mint, evidence-oid4vci) are always lowercase and monospace, and are never used as the product name in prose. Write “Registry Relay refuses the request”, not “relay refuses the request”.
Legacy underscore forms (registry_relay) and old repo names (decentralized-evidence-demo) appear only in historical pages or rename_status fields.
The glossary provides a reference for standards acronyms but does not replace per-page first-use expansion.