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). Base Registry Engine uses the same two words and the same accessProfile request parameter for a different object: a named grant inside the registry project stating which scopes, purposes, and claims a token must carry and which operations, fields, and rows the caller may reach. See Control access per profile.
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. 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.
accountability record: The protected state Registry Casework keeps beside a hosted item’s terminal outcome: the deciding person’s issuer-qualified identity and the staff reason, held for the hosted kind’s accountabilityDays. The Requester’s terminal feed carries an opaque actor reference instead. A Supervisor who currently leads a team serving the item’s queue resolves one terminal eventId through the separate accountability route, and that read is audited. See Retain, erase, and settle.
attempt: Registry Casework’s accountable action against a source: the runtime presents the deciding person’s own token under the selected source profile and asks the source system to apply the decision. The source keeps eligibility and mutation authority, so an attempt can be confirmed, refused, or left uncertain when the source’s answer never arrived; an uncertain attempt is preserved for recovery, never retried on its own, and an operator settles it with caseworkctl attempt settle once the outcome is confirmed with the source owner.
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.
audit journal: The hash-chained record of admitted work that Base Registry Engine keeps in the registry’s own PostgreSQL database. Every write path appends one audit record, and the journal keeps its own head. bregctl audit verify walks that chain from the recorded head backwards, audit export takes a portable copy, and audit prune retires its oldest part under a retention boundary. All three read envelope bytes, hashes, envelope identifiers, and timestamps only, so no record value reaches a report or a refusal, and an erasure never removes audit records. See Retain, erase, and audit.
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 deployment, and the reviewed input a package is sealed from. For Registry Relay it holds 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. bregctl uses the same two words for a Base Registry Engine registry project. In both products the project is the reviewed input and the package is what an operator deploys. See the relayctl command reference.
authoring workspace: The editable Evidence Gateway project evidencectl init starts from exactly one OpenAPI or SQLite source: the sources, questions, schemas, derivations, and fixtures an author writes. 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 package compiles one workspace and one explicit target into a production candidate, which an operator mounts as a deployment project. evidencectl package --help calls the workspace an editable Evidence Gateway project.
Base Registry Engine (product): The governed writable system of record in this monorepo. Base Registry Engine (BReg) is a PostgreSQL system of record whose data model and REST API are compiled from a registry project. The runtime carries no built-in domain types, so a business, a plot, a permit, or an asset exists only when the active package declares it. It verifies bearer tokens and issues none, enforces access profiles and row boundaries on every request, and appends each admitted request to the audit journal in the same database. Crate: crates/registry-breg; binaries breg (runtime) and bregctl (adopter tooling); repo slug: registry-breg. It was named Registry Server before the naming decision, and that name survives only in an explicit rename note.
BReg: The short technical family name for Base Registry Engine, and the stem its binaries, crate, client module, and configuration keys use. Write the formal name on a page’s first use, Base Registry Engine (BReg), then BReg for the rest of that page. BREG, Breg, and B-Reg are not spellings of it.
bounded question: The kind of question Evidence Gateway answers: one predefined, versioned question with a closed set of supported values, evaluated against a source and answered without returning the source record. Bounded is what makes the product safe to point at sensitive data, because a caller can ask only what the deployment already declared and what the caller’s grant already permits, and no request parameter, header, or token claim widens the answer. An author writes a bounded question under questions/<name>.yaml; after evidencectl compiles it, the same object is a requirement.
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.
calendar: In Registry Casework, the working week and time zone an activity clock counts against, declared in the policy with a named holiday set whose dates arrive separately as a holiday revision. A project declares at most 16 calendars.
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.
change request: In Base Registry Engine, a record of its own that proposes a change to another entity’s record, waits for review, and is applied later by a profile that holds apply authority. A change-request entity declares its review stages, application policy, and retention, and it may declare a planner in place of fixed effects. See Declare change requests and actions.
claim: In Registry Casework, the act by which a Staff member takes a visible work item into their own holdings, under a revision the caller must echo with If-Match. A claimed item carries a private draft for its holder, can be delegated or released, and is moved by a Supervisor through a review-then-apply caseload movement. Evidence Gateway uses the same word for a JWT claim, a named value inside a token.
claim level: The evidence discipline these docs use for standards claims: implements, emits, maps_to, aligns_with, inspired_by, or compares_against.
clock: In Registry Casework, a policy rule that says when work is late. A subject clock measures a whole request from a source timestamp to a source event and can pause while the source waits on someone outside the team. An activity clock measures one stage in working days against a calendar and can record a reminder or, when due, release the holder and move the item, under the system actor, after a fresh source read. A clock decides no outcome and sends nothing outward. A project declares at most 32 clocks.
configurationRevision: The sha256: digest an Evidence Gateway assertion carries for the configuration and artifact closure that requirement’s evaluation reached (products/evidence/contracts/evidence.schema.yaml). It is scoped to the requirement, not to the whole deployment, so an edit that cannot change an assertion leaves that assertion’s revision alone. Changing container paths or listener bindings moves the runtime revision instead.
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.
dataset: In a Base Registry Engine project, the value of an entity’s required primaryDataset, naming the dataset its records belong to. The compiler checks that value against manifestProjection.datasets[] only when the project declares a manifestProjection block; a project without one may use any non-empty string, and bregctl check accepts it as written. Registry Manifest catalogs and Registry Relay statistical datasets use the same word for their own unrelated shapes.
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.
directory: Registry Casework’s runtime record of teams, their members and leads, the queues each team serves, and declared absences. An Administrator bootstraps and maintains it through the authenticated directory API under If-Match revisions; it is not part of the policy package. Team service is a second authority check on every human call, so a queue nobody serves has no inbox, and caseworkctl doctor reports it. See Deploy Registry Casework.
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. It is the compiled output an operator deploys, not the thing an author edits: that is the authoring workspace, and evidencectl package compiles one workspace and one explicit target into a 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 three released binaries evidence, evidencectl, 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 three-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. 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 business-registration portal, procurement service, licensing authority, environmental reporting service, 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.
erasure: The irreversible removal of retained detail from a Base Registry Engine registry under an approved retention request. bregctl history erase removes the retained revisions of one record up to a revision number, the correction context and retained outbox payloads that referenced them, and the cached idempotency responses that could replay them. bregctl request-retention erase removes the payload detail of one change-request proposal version. Neither touches the current record, later revisions, or the audit journal, and neither has a dry run. A rebaseline restores snapshot coverage afterwards. Registry Casework uses the same word for caseworkctl retention erase, which removes Casework’s own retained payload copies of one source request, keeps payload-free tombstones, and makes no call to the source. See Retain, erase, and settle.
eSignet: Open-source identity and authentication service (part of MOSIP). No Registry Stack service integrates with it directly. Evidence Gateway authenticates callers against one configured OIDC issuer and key set named in its immutable bundle, and names no specific identity product. A separately maintained eSignet provider can authenticate citizens against a Base Registry Engine registry through one governed lookup; see Authenticate citizens with eSignet.
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).
holiday revision: In Registry Casework, a dated list of public holidays for one named holiday set, published to a running deployment by an Administrator rather than written into the policy, because holidays are announced on their own schedule. A new revision drives a reviewed recompute of the activity clocks that count against a calendar naming that set.
hosted item: A Registry Casework work item the runtime holds in full: a Requester service creates it under a declared hosted kind with an Idempotency-Key, a Staff member in the kind’s deciding profiles claims and decides it, and the Requester pages the outcome from its terminal feed. No source system is involved, so a standalone deployment needs no Base Registry Engine.
hosted kind: A policy declaration in casework.yaml for one kind of hosted item: its version, the queue it lands in, the profiles that may decide it, its closed display schema, its outcome vocabulary with per-outcome reason rules, and its retention periods (terminalDays, accountabilityDays). Casework pins the kind version and policy digest on each item it accepts, so a later policy change does not rewrite existing work. See Author a Casework policy.
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.
journey: One of the scenarios in tests/journeys.yaml that bregctl test replays over HTTP against a throwaway database, because a row boundary, a query bound, or a review workflow is only proven by a request that runs. A fully successful run writes a receipt. See Test with journeys.
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.
module: A reusable file under modules/<id>/module.yaml that contributes entities, vocabularies, events, and extensions to entities declared elsewhere, so a part of a Base Registry Engine model can be reviewed and versioned separately from the registry project that adopts it.
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.
outbox: A table in a Base Registry Engine registry’s own database that takes one row per configured event, written inside the same transaction as the record change that raised it, which the webhook worker inside breg then reads and delivers.
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: The compiled and verified form of one Base Registry Engine registry project: bregctl builds it, breg serves it, and a production package carries detached signatures from keys the deployment’s trust anchor names. breg verifies the active package at startup and answers only the routes that package compiled. Registry Relay’s counterpart is the sealed package, which relayctl builds and which is unsigned.
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.
planner: A bounded Rhai script a Base Registry Engine change-request entity declares in place of fixed effects, which reads one submitted request and returns the record writes to apply and, where the project allows it, whether to apply the request or queue it.
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.
private draft: The working notes a Registry Casework holder keeps on a claimed work item before deciding. Only the holder reads or writes it; a release, delegation, or caseload movement hands the item on without it, and the decision is what becomes visible, never the draft.
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 Manifest, Registry Relay, Base Registry Engine, Registry Casework, Evidence Gateway, and Registry Discovery. 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.
queue: A named inbox declared in a Registry Casework policy. Source-backed requests and hosted kinds route into a queue; a team in the directory serves it, and only members of a serving team see its items. Routing rules and clock steps may move an item to another queue under actor system:clock.
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.
rebaseline: The Base Registry Engine maintenance run that restores snapshot coverage after a history erasure, by proving every live row still matches its retained journal head and installing one baseline commit at that head.
policy package: In Registry Casework, the directory caseworkctl package writes from a verified project: the policy file, the exact imported source descriptions, and a manifest of their digests. The casework runtime rebuilds the manifest at startup and refuses to serve a package with a changed byte, a missing file, or an extra file, so the package is what an operator deploys and what a policy change replaces whole.
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.
receipt: The JSON document a fully successful bregctl test run writes, recording the candidate package revision, the source closure, the deployment and database identity, the target schema fingerprint, and the journeys that passed, so packaging can refuse a receipt taken for anything else.
Registry Casework: The coordinated inbox product in this monorepo: authorized human teams claim, draft, and decide work items that a source system owns or that a Requester service submits as hosted items. It verifies bearer tokens and issues none, requires the issuer’s human-identity assertion for Staff, Supervisor, and Administrator, and leaves eligibility, visibility, and registry mutation with the source. Crates: crates/registry-casework (runtime, binary casework) and crates/registry-caseworkctl (adopter tooling, binary caseworkctl); client module casework in the unified clients. Short form on a page after first use: Casework. See the Registry Casework overview.
Registry Discovery: The read-only public index in this monorepo. A catalog operator maintains provider URLs and evidence-type mappings for the Evidence Gateway and Registry Relay providers that operator has chosen to index, discoveryctl check and discoveryctl build produce one immutable index offline, and the discovery binary serves that index until it is restarted with a newer one. Discovery carries inert public metadata: it makes no authorization decision, serves no record, and answers no question. Crate: crates/registry-discovery; binaries discovery and discoveryctl; repo slug: registry-discovery. Write Registry Discovery on a page’s first use and Discovery after it. See Build and run a Registry Discovery index.
registry document: Disambiguation. Base Registry Engine and Registry Relay each compile a file named registry.yaml, and the two grammars are unrelated. Relay’s is the Registry contract (kind: RegistryContract), compiled by relayctl; BReg’s is the root of a registry project, compiled by bregctl, and declares entities, fields, relationships, access profiles, change requests, and events. Both use the words access profile for different objects. Where both products are in view, prose writes the BReg registry document and the Relay registry document. A snippet copied from the other product’s page does not compile.
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 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. Base Registry Engine serves the records of its own registry under the same shared Registry Record profile, in the Registry Record envelope.
Registry Record envelope: The single shape every Base Registry Engine read, create, patch, tombstone, revision, and snapshot response returns. data.recordIdentifier is the record’s stable UUID, data.revisionIdentifier a string revision counter starting at 1, and data.domainData the entity’s fields under their apiName, narrowed to the grant’s readable fields and to $select. Mutation responses add data.snapshot, change-request records add data.request, and a grant declaring requestPresence adds data.requestPresence. meta carries the registry, dataset, and entity identifiers from the compiled package, and a collection read returns items and a pageInfo object instead of a single data. A field name that would collide with an envelope member is refused at compile time. See the Base Registry Engine API reference.
registry project: The directory of YAML files an adopter writes for one Base Registry Engine registry, registry.yaml plus optional modules and journeys, declaring the entities, fields, relationships, access profiles, change requests, and events that registry exposes. bregctl init writes a starter project; bregctl check, explain, and generate compile and inspect it without opening a database; bregctl test replays its journeys against a throwaway database; bregctl package builds the package an operator activates. bregctl --help also calls it an authoring project. See Author a registry project.
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. An author writes the same object as a question under questions/<name>.yaml; requirement is what that question is called after evidencectl compiles it.
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.
Rhai: The bounded scripting language both Evidence Gateway and Base Registry Engine embed for adopter-authored logic, reviewed with the rest of the configuration. Evidence Gateway uses it for requirement-specific derivations, which read the facts, selectors, and context the host gathered and return the answer. Base Registry Engine uses it for change-request planners, which see only the submitted request’s fields and may write only what the project’s YAML declares.
row boundary: A rule in a Base Registry Engine access profile that binds one record field to a verified claim in the caller’s token with equals or in, so a request reaches only the rows whose field matches what the token carries.
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 profile (Casework): In Registry Casework, the value a caller sends in Registry-Source-Profile to act on source-backed work. It names the source-side access profile under which Casework presents the caller’s own token to the source for reads and for the accountable attempt, so source visibility and action authority stay with the source. Omitting the header selects hosted work, and hosted-only routes refuse it. Registry Relay uses the same two words for the unrelated snapshot or live-read-only declaration.
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.
team: A directory entry in Registry Casework: a named group with members, leads, and the queues it serves. Membership decides what a Staff member sees, and leading a serving team decides what a Supervisor may move, cover, or read from an accountability record.
terminal feed: The Requester-facing, cursor-paged list of terminal outcomes for the hosted items one Requester created under one issuer, subject, and profile. Each event carries the outcome, the reason when the kind requires one, and an opaque actor reference. Events leave the feed when the kind’s terminalDays elapse, so a Requester polls within that period and deduplicates by eventId.
Transit proxy: The workload-local Vault or OpenBao Transit proxy an Evidence Gateway deployment reaches over a Unix socket to sign assertions in production and evidence-grade mode. The operator runs it beside the service, so Evidence Gateway holds no signing key of its own in those modes. Local assurance may use an owner-only P-256 private JWK under the secret root instead.
trust anchor: The file a Base Registry Engine runtime configuration names, listing the public keys whose signatures a package may carry and how many of them must sign, bound to one environment, one deployment instance, and one database.
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.
work item: The unit of work in Registry Casework: one item in one queue with a holder, a revision, history, and clocks. A source-backed item mirrors a governed change request a Base Registry Engine holds, so Casework keeps assignment, routing, clocks, drafts, and recovery while the registry keeps eligibility, visibility, and the mutation; a hosted item lives in Casework in full. A caller that may not see an item gets the same answer as for an item that does not exist.

Style notes

Formal product names (Registry Platform, Registry Relay, Registry Manifest) 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, 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 (breg, bregctl, casework, caseworkctl, discovery, discoveryctl, relay, relayctl, evidence, evidencectl, evidence-oid4vci, and registry-manifest) 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.