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 Base Registry Engine grant stating which scopes, purposes, claims, operations, fields, and rows a 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.
authoring project: A local directory an adopter writes as reviewed product input. Each product owns its project shape and compiler.
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/<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 a Registry Stack service.
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.
consumer decision: An eligibility, qualification, prioritization, approval, routing, payment, workflow, or other outcome determined outside Registry Stack by or for an evidence consumer.
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.
dataset: In a Base Registry Engine project, the value of an entity’s required primaryDataset, naming the dataset its records belong to. Registry Manifest catalogs use the same word for their own shape.
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, so this is not atomic project activation. 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 product instances. Each product stages and activates its own configuration.
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. The OID4VCI supporting service accepts a self-contained did:jwk#0 proof-key reference and never performs remote resolution.
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 each product publishes documented, standards-shaped contracts. Registry Manifest renders portable metadata and Evidence Gateway can serialize SD-JWT VC under its frozen profile.
JSON-LD: JSON-based linked data format. W3C recommendation (JSON-LD 1.1). Registry Manifest uses it for catalog and policy render output.
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. It contains publication metadata rather than runtime bindings.
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.
OGC API Records: Open Geospatial Consortium API specification for records. Registry Manifest renders an OGC Records item collection.
OGC API Features: Open Geospatial Consortium API specification for feature collections and items. No maintained Registry Stack runtime claims 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.
package: The compiled and verified form of one product’s reviewed authoring input.
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. No maintained Registry Stack runtime exposes a general external policy-decision point.
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.
registry stack: The product family including Registry Platform, Registry Manifest, Base Registry Engine, Registry Casework, Evidence Gateway, Registry Discovery, Registry Render, Registry Scheduling, and Registry Messaging.
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 evaluated against an explicit purpose limitation or context-aware authorization rule.
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: An authorization value a protected operation requires from a verified caller credential. 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.
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 identifier, revision, lifecycle state, and recorded-at context that lets a consumer distinguish one version of a Registry Record from another.
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. Current profiles index Evidence Gateway provider descriptions and evidence-type mappings. Published v1alpha1 packages may retain historical provider capabilities, but a mixed index must be rebuilt before current serving.
registry document: The root registry.yaml of a Base Registry Engine registry project.
Registry Manifest: Portable Rust library and CLI for modeling, validating, and rendering standards-facing metadata without running a service.
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 Record: The neutral strict record representation used by Base Registry Engine clients and APIs.
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: A retired Registry Stack product. Version 0.38.0 was its last numbered release; 0.39.0 is the first release without it. See the retirement decision.
Registry Stack project: Retired term for a shared authored root. Current products are authored and deployed independently.
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 (retired Relay term): A named collection in the retired Registry Relay read-only publication contract. Current Base Registry Engine projects declare entities and operations instead; Evidence Gateway projects declare fixed sources and requirements.
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.
source profile: A product-specific declaration constraining how a fixed source is accessed.
source profile (Casework): The value a human caller sends in Registry-Source-Profile to act on source-backed work or read source-context review tasks.
source: A named data interface a product reads through its fixed source contract.
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.
registry-manifest/v1: Schema version string for portable metadata manifests.
reviewability: Commitment that stack promises are backed by inspectable contracts, artifacts, tests, or audit evidence.
runtime binding: Deployment-local settings that connect reviewed product input to one operated environment.
safeguards: Technical and institutional controls that keep an exchange authorized, bounded, auditable, and subject to accountable governance.
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.
SHACL: Shapes Constraint Language. Registry Manifest emits SHACL node shapes for published entity schemas.
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 inventories portable metadata and linked-data outputs. It can be hosted as static files.
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 deployment.
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 maintained product names use title case. Retired product names remain title case only in explicit historical context.
Repo slugs and binary names are lowercase and monospace.
Legacy underscore forms 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.