Registry stack documentation: machine-readable Markdown. Index of all pages: https://docs.registrystack.org/v/0.38.0/llms.txt Full corpus: https://docs.registrystack.org/v/0.38.0/llms-full.txt # Glossary > Shared product names and domain terms for the registry stack documentation. Use this page to look up unfamiliar terms. Product names are always in English, including on future translated pages. {/* Do not translate contract identifiers, env vars, media types, route paths, schema versions, crate names, or Docker image names. */}
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 accepts access tokens from one OIDC issuer, `authentication.oidc`, whose issuer, single audience, accepted token types, algorithms, fixed 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 terminal review decision: the deciding person's issuer-qualified identity, profile, private reason, and result digest, held for the review kind's `accountabilityDays`. Producer-visible results carry none of that identity or private reason. An authorized Supervisor resolves one event 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. A pending attempt that the actor who started it can no longer recover is first marked uncertain with `caseworkctl attempt mark-uncertain`.
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 minimized request and response entries that Base Registry Engine writes to a per-process file or stdout stream, separately from PostgreSQL. Entries use keyed references and a shared request correlation. File appends are durable; stdout is best-effort. Rotation and retention bound local files. Operators ship the stream to append-only storage for tamper evidence and completeness. An erasure does not remove audit entries. 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 through a separate per-process writer. 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/.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 package 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 package, so an edit that cannot change an assertion leaves that assertion's revision alone. A signing-key rotation or revocation leaves it alone too, because key trust travels in the JWKS and the verification policy's denylist, and so does revoking a caller token key, which decides who may call rather than what an assertion means. Runtime-only path or listener changes leave both the package digest and requirement revisions unchanged.
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
An Evidence Gateway input form used by deployment inspection and fixture tooling: a directory with `runtime.yaml` whose `package.root` names the installed package. The current authoring flow keeps these inputs separate: `evidencectl package` compiles an authoring workspace and explicit target into one closed package, while the target retains `runtime.yaml`. Evidence Gateway verifies the package and captures the runtime read-only at startup; a new package 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.
review request
A source-neutral Registry Casework request created by an admitted producer under one review kind. It binds an immutable subject, policy identity, submission digest, submitted snapshot or source context, staged reviewer tasks, terminal result, and retention. A submitted-context deployment needs no Base Registry Engine.
review kind
A policy declaration in `casework.yaml` for one kind of review request: its purpose, context strategy, ordered stages, thresholds and reviewer exclusions, closed display and result schemas, outcomes, clocks, and retention (`terminalDays`, `accountabilityDays`). Casework pins its version and digest on each accepted request. 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//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 and `breg` serves it. `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.
package digest
The `sha256:` digest of a package's `SHA256SUMS` file, which lists the digest of every other file in the package. Every product that serves a package reports this value and accepts it as `package.expectedDigest`, so two operators can confirm they run the same reviewed bytes. It is an integrity digest, not an authenticity proof: 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 work and review stages route into a queue; a team in the directory serves it, and only eligible members of a serving team see its work. Routing rules and clock steps may move source work 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 `SHA256SUMS` file listing their digests. The `casework` runtime rechecks every digest 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's registry revision, the source closure, the package it succeeds, the target schema fingerprint, and the journeys that passed, so packaging can refuse a receipt taken for anything else.
Registry Casework
The coordinated inbox and unified-review product in this monorepo: authorized human teams claim, draft, and decide source work items or review requests from admitted producers. It verifies bearer tokens and issues none, requires the issuer's human-identity assertion for human roles, and leaves source eligibility, visibility, and 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 package` produce one immutable index package offline, and the `discovery` binary serves that package 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 Package 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: RelayRuntimeConfig`), 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/.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 authored `registry.yaml` and governed files, the compiled contract, the generated artifacts, and a `SHA256SUMS` file listing the digest of every other file. Relay refuses a package with a changed, missing, or extra file, and it recompiles the packaged contract and regenerates the artifacts at startup, refusing a package whose compiled contract or artifacts the packaged inputs do not reproduce. Packages are unsigned: verification proves integrity, not authorship. See package digest.
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 human caller sends in `Registry-Source-Profile` to act on source-backed work or read source-context review tasks. It names the source-side access profile under which Casework presents that caller's token. Source visibility and action authority stay with the source; submitted-context review tasks need no source profile. 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/` or `secret:file/`, where `` 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.
result feed
The producer-facing, cursor-paged list of terminal results for review requests created under one exact producer binding. Events carry a stable identifier and terminal result without raw reviewer identity or private reason. Events leave the feed when the kind's `terminalDays` elapse, so a producer 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 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 source-work coordination record in Registry Casework: one item in one queue with a holder, revision, history, and clocks. It 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 mutation. Unified review work uses a separate request and task model.
## 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. {/* Contributor rules: do not use legacy underscore forms or old repo names in prose on current pages; spell out standards acronyms on first use per page. */}