Glossary

View as Markdown

Product names are always in English, including on future translated pages.

access profile: A named grant a caller selects with its token. In Base Registry Engine (BReg), it states which scopes, purposes, claims, operations, fields, and rows the caller may reach; see Control access per profile. In Registry Casework, an entry under accessProfiles admits a token carrying its requiredScopes, takes the caller’s identity from principalClaim, and gives one role: staff, supervisor, administrator, or requester; see Author a Casework policy.
accountability record: The protected record Registry Casework keeps of who made a Decision and their private reason, held for the pinned policy’s accountabilityRetentionDays and never sent to the producer. See Retention in Casework.
Action: A BReg typed operation with one bounded Plan and a fixed execution mode. An immediate Action commits its effects atomically and returns an ActionReceipt; a proposal Action starts a durable Proposal.
ActionReceipt: The response to a successful immediate Action: its applicationId and, under results, the Record type, recordId, and new revision of each effect the caller may see. A refused invocation leaves no partial change.
appointment: A confirmed claim on Registry Scheduling capacity, made from a hold or directly, that the caller may reschedule or cancel within the offering’s cutoff. Each change advances its revision.
assertion: Registry Evidence’s answer: a signed payload that carries the answer to one requirement and none of the record behind it. Signed flattened JSON Web Signature (JWS) is the default serialization; SD-JWT VC carries the same assertion.
assertion definition: One fixed question in an Evidence project, declared under assertionDefinitions with its Requirement URI, purpose, subject roles, source, permitted outputs, and the grant ceiling no caller can exceed.
audit journal: The minimized request and response entries Base Registry Engine writes to a per-process file or stdout stream, separately from PostgreSQL; operators ship it to append-only storage. An erasure does not remove audit entries. See Retain, erase, and audit.
Base Registry Engine (BReg): The PostgreSQL system of record whose data model and REST API are compiled from a registry project, with no built-in domain types. Binaries breg and bregctl.
calendar: In Registry Casework, the working week and time zone a clock counts working days against, with a named holiday set whose dates arrive as a separate revision.
claim: In Casework, taking an eligible ReviewTask into a reviewer’s holdings at its current revision, before they decide, release, or delegate it. A JWT claim is a separate meaning: a named value inside a token.
clock: A pinned Casework policy rule that measures a subject or a stage against a deadline, in elapsed time or working days on a calendar. It can send a reminder or move a due task to another queue, and never decides an outcome.
configurationRevision: The sha256: digest a Registry Evidence assertion carries for what its assertion definition does, which relying services pin. It moves with the source request or response shape, selector profiles, Functions, codelists, schemas, outputs, or validity, and stays put for question text, fixtures, endpoints, credentials, grants, and signing keys.
content verification: The Registry Document Store’s check of every stored document version by an operator-configured verifier, which receives the bytes and answers approved or rejected. Only an approval bound to the version’s digest, media type, and the current verifier releases it; a rejection keeps it from ever being released. Base Registry Engine applies the same check to Proposal attachments.
context provider: The source’s read-only review interface a Casework policy names under context.mode: current-source. Casework asks it again under each reviewer’s own credential when a task opens and keeps none of the source’s data.
Decision: One reviewer’s recorded choice of an outcome the ReviewPolicy declares. Casework counts decisions against each stage’s threshold and settles the ReviewRequest.
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 uses its own bundle, and no Registry Stack component binds or atomically activates them, so this is not atomic project activation.
deployment candidate: The directory evidencectl package writes from an Evidence project and one target: an immutable bundle/, a runtime file, and a compiled authority. Its package digest identifies the bundle.
directory: Registry Casework’s runtime record of teams, their staff and supervisors, and the queues they serve, maintained by an administrator through the directory API under revisions. See Staff the directory.
document: In the Registry Document Store, a record reserved under one document policy by an owning system, holding one immutable document version. Its custody is fixed when it is reserved. A Registry Render PDF can become a document’s bytes, but the two products do not call each other.
document custody: Who holds a Registry Document Store document, fixed by its policy: the person it was placed for (represented-principal) or the institution whose system reserved it (institution). Only the custodian may remove the document.
document grant: A Registry Document Store release of one exact, ready document version to one named recipient until a fixed expiry within the policy’s bounds. It keeps its expiry; who may hold it follows the active package, so a policy change applies to grants already issued. Revoking it or letting it expire erases nothing.
document version: One immutable upload of a Registry Document Store document’s bytes, checked against the digest and length declared when it was reserved. Its status moves from awaiting-content through pending to ready after content verification, or to rejected, which it reads until its bytes are erased. A ready version reads suspended while it is not releasable, such as while a changed verifier checks it again. Removal moves it to erasure-pending and then erased, and its record stays.
erasure: The irreversible removal of retained detail under an approved retention request. In Base Registry Engine, bregctl history erase and bregctl proposal-retention erase remove retained revisions or Proposal detail, never the current record or the audit journal; Registry Casework erases expired review data through runtime maintenance. In the Registry Document Store, removing a document or a rejection erases its bytes after the policy’s grace period and keeps its record. Erased bytes stay on PostgreSQL pages until they are overwritten, and backups, replicas, and the old versions a versioned bucket keeps hold their own copies.
Registry Evidence: The minimum-disclosure assertion product: it answers one predefined question from a fixed read of your system with a signed assertion, never the source record. Binaries evidence and evidencectl.
Evidence project: An evidence.yaml file and the scripts it names, kept in version control, declaring assertion definitions, sources, selector profiles, and Functions. evidencectl checks, tests, and packages it with a target into a deployment candidate.
Function: A project-local typed implementation asset. In BReg, an Action’s Plan uses one to compute effects within the Action’s declared write ceiling; it cannot grant authority or invent a review decision. In an Evidence project, a Rhai script with a declared interface that turns a source response into facts or facts into declared outputs, under fixed operation and size limits. In a Registry Coordinator workflow, a Rhai script that routes a choose step or computes a value a call’s input maps with type: function, with no clock, file, network, database, or credentials.
grant ceiling: The widest authority a Registry Evidence assertion definition lets any grant give for it: the authorities, actor kinds, value origins, and audiences a grant may name. A target authority’s grant may only narrow it; Registry Evidence refuses to activate one that widens it.
hold: A short-lived claim on Registry Scheduling capacity that expires on its own unless the caller confirms it into an appointment.
holder-bound: The Registry Evidence subject binding mode in which the binding derives from the holder key’s RFC 7638 thumbprint instead of the audience. Its requirement returns only SD-JWT VC, and the relying party checks the audience at presentation by verifying a key-binding JWT.
holiday set: A named list of dates an opening excludes.
journey: One scenario in tests/journeys.yaml that bregctl test replays over HTTP against a throwaway database. A fully successful run writes a receipt. See Test with journeys.
module: A reusable modules/<id>/module.yaml file that contributes Record types, value types, Functions, Actions, and additive extensions to a Base Registry Engine registry project.
offering: One bookable Registry Scheduling service at one location, in exact-time or arrival-window mode, drawing on a resource pool or on published windows.
OID4VCI: OpenID for Verifiable Credential Issuance. The registry-evidence-oid4vci supporting service implements a frozen OID4VCI 1.0 Final profile to deliver holder-bound dc+sd-jwt credentials to a wallet; Registry Evidence signs them.
opening: The weekly hours on which an exact-time offering publishes start times, minus its holiday sets.
outbox: A table in a product’s own database that takes one row per event or intent to deliver, written in the same transaction as the change that caused it, so a worker delivers it after the commit and a slow receiver never blocks the change. A Base Registry Engine registry’s outbox feeds the webhook worker inside breg; Registry Scheduling’s holds reminder intents and observer events.
package: The compiled and verified form of one product’s reviewed authoring input.
package digest: The sha256: digest of a package’s SHA256SUMS file, reported by every product that serves a package and accepted as package.expectedDigest. It is an integrity digest, not an authenticity proof: packages are unsigned.
Plan: The effects an Action makes, authored under plan: a type: fixed Plan lists them in order, and a type: function Plan names a Function that computes them within the Action’s declared writes.
policy package: The directory caseworkctl package writes from a checked Casework project, with its exact SHA256SUMS. The runtime verifies that closure before serving and refuses a changed, missing, or extra file.
producer: The system that sends Registry Casework a ReviewRequest and reads its ReviewResult, declared under trustedProducers. It authenticates independently of the human reviewers.
Proposal: BReg durable work created by a proposal-mode Action. Submission freezes its inputs, effects, target revisions, and the review it requests; BReg applies that exact plan automatically by default, or manually when configured.
Proposal attachment: A file uploaded into one declared slot of a Base Registry Engine Proposal, held by BReg and bound by digest when the Proposal is submitted. It is separate from a Registry Document Store document. See the BReg API reference.
purpose: The authorized reason a caller gives for a Registry Evidence request: a configured code from the definition’s declared purposes and the caller’s grant, echoed into the assertion. In Base Registry Engine, an access profile’s requiredPurposes lists the purposes it accepts.
queue: A named Casework inbox that stages, routing, and clock steps send tasks to. A person reaches its tasks only as a member of a team serving it.
rebaseline: The Base Registry Engine maintenance run, bregctl history rebaseline, that restores snapshot coverage after a history erasure by verifying every live row against its retained journal head.
receipt: The JSON document a fully successful bregctl test run writes for one exact candidate, recording the journeys that passed, so packaging can refuse a receipt taken for anything else.
Record (Registry Record): One stored row of a BReg Record type, with a stable UUID and a revision counter each committed change advances. Registry Record v1 is the strict shape BReg and its clients return it in; see the Base Registry Engine API reference.
Record type: The BReg definition of one kind of Record: its fields, route, dataset, and mutationPolicy, authored under recordTypes.
Registry Casework: The human-review product: a producer sends a ReviewRequest, authorized people decide its ReviewTasks, and the producer reads the result. The source keeps its data, its disclosure, and all authority to change it. See the Registry Casework overview.
Registry Coordinator: The workflow product: it runs a reviewed workflow of product calls and waits, started by an authorized caller or by a signed event from a trusted event source, and keeps each run going across outages and restarts. Every product it calls keeps its own authority and data, and the Coordinator is never a review provider. See the Registry Coordinator overview.
Registry Discovery: A curated, read-only index that tells an application which Evidence types meet a requirement and which Registry Evidence services assert them. It holds no credentials and vouches for no provider; trust stays with the application. See the Registry Discovery overview.
Registry Document Store: The document custody product: it holds document bytes for the system that owns them and releases one verified version to each recipient a document grant names. Binaries documents and documentsctl; pre-1.0 and held out of releases.
Registry Manifest: The Rust library and registry-manifest command that check one portable metadata.yaml and render it into standards-shaped metadata, without running a service. See the Registry Manifest overview; the Registry Manifest reference is authoritative for the current top-level keys.
Registry Messaging: The notification product: it sends one message to one destination over one channel for an authorized caller, rendered from a reviewed template through an operator-configured provider, and reports what is known about delivery. Why and when to send, to whom, and whether the person agreed to be contacted stay with the caller. See the Registry Messaging overview.
registry project: The directory of YAML files an adopter writes for one Base Registry Engine registry: registry.yaml plus optional modules and journeys. bregctl checks, tests, and packages it. See Author a registry project.
Registry Render: The document rendering product: it renders PDF documents from registry data through Typst, byte for byte the same for the same inputs, as a service with an audit journal or as a command line for authoring and counter printing. See the Registry Render overview.
Registry Scheduling: The booking product: it publishes bookable services over supply the operator anchored and gives authorized callers short holds and confirmed appointments, with every capacity decision made in one transaction under a task grant. See the Registry Scheduling overview.
Registry-Source-Profile: The header a Casework reviewer sends to select the source’s access profile for work whose context comes from a context provider, which reads under that profile and the reviewer’s own credential. Producer, policy, and accountability routes refuse it.
requirement: The question a Registry Evidence assertion definition answers, named by a stable Requirement URI such as urn:example:requirement:adult-status:v1 that a caller sends. A change in meaning gets a new URI.
resource pool: The operator-anchored set of resources, such as counter stations, that an exact-time offering draws on. It is an environment record applied to the database, not part of the policy package.
ReviewPolicy: The Casework declaration under reviewPolicies that fixes a review’s context, stages, schemas, outcomes, routing, clocks, and retention; its ID, version, and digest are pinned at acceptance. See Author a Casework policy.
ReviewRequest: What a producer sends Casework: the subject to review and the ReviewPolicy to review it under. Casework pins the policy’s binding and a submissionDigest when it accepts the request.
ReviewResult: The immutable terminal answer a producer reads for its ReviewRequest: subject, policy binding, submissionDigest, status, outcome, and any public reason. It never names the reviewer and grants no authority to change the source.
ReviewTask: One human contribution to a ReviewRequest, created when a stage becomes active, with its queue, revision, holder, and Decision.
Rhai: The bounded scripting language for adopter-authored Functions, run under fixed operation and size limits. Registry Evidence Functions extract facts and derive outputs; Base Registry Engine Functions compute an Action’s effects; Registry Coordinator Functions route a choose step or compute a mapped call input.
row boundary: A rule in a Base Registry Engine access profile that binds one record field to a verified token claim with equals or in, so a request reaches only matching rows.
run: One admitted execution of a Registry Coordinator workflow. A run keeps the workflow revision it was admitted under, so a later upgrade never changes a run in flight.
scheduling fixture: A YAML case that schedulingctl test replays offline against a Registry Scheduling policy and its records, stating the bookings it expects to succeed or be refused.
scheduling hook: An after URL observer for appointment.confirmed, appointment.rescheduled, or appointment.cancelled. It receives a closed projection of the appointment after the capacity transaction commits and cannot change the outcome.
SD-JWT VC: Selective Disclosure JWT Verifiable Credential (IETF draft), the second serialization Registry Evidence offers for the same stateless assertion under its frozen profile. It adds no credential lifecycle. Media type: application/dc+sd-jwt.
selector profile: The bound on what a caller may send to identify a subject in a Registry Evidence request, declared in the Evidence project: the fields, their sizes, and the aggregate limit. A source takes its request values only from those fields.
source: One fixed read an Evidence project declares: an HTTP request with one method and path template, or one SQL statement over a read-only SQLite extract, with the response shape it accepts and the fields it may read. Registry Evidence reaches a source with the credential its target binds, never the caller’s.
stage: One step of a ReviewPolicy, run in order, naming its queue, the profiles that may decide, and how many independent reviewers must approve.
subject binding: The opaque value that stands for a subject in a Registry Evidence assertion in place of its identifier. An audience-scoped binding differs for each relying audience, so two cannot join their answers; a holder-bound binding derives from the holder’s key instead.
target: The operator-owned file, such as local-target.yaml, that binds an Evidence project to one deployment: the token issuer, each source’s endpoint and credential, the signer, and the audit path. Its target authority names the access profiles that may call and the grants each holds.
task grant: The signed claim in a caller’s access token that names the Registry Scheduling service, location, and actions another system has allowed. It is matched exactly before the capacity transaction opens, and its expiry is checked again immediately before the claim commits.
team: A named Casework group that serves queues and declares the profiles its members and supervisors must hold; its membership lives in the directory.
wait: A Registry Coordinator step that holds a run until an instant (wait-until) or until a named completion an earlier accepted call exposes (wait-for), such as a Casework ReviewResult. A wait never renews an approval or creates downstream authority.
workflow: A finite graph of steps in YAML that Registry Coordinator checks offline and packages into an immutable artifact an operator pins by digest. Its five step types call one product operation, choose the next step, wait, or finish.

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.