Changelog

View as Markdown

This page records notable changes to the documentation site and the product versions it documents. Per-product release notes live in each product repository; the entries below link to the relevant product pages on this site rather than duplicating release notes.

Unreleased

v0.34.0 beta-46

bregctl apply reports a migration database it could not reach, or an apply lock another session held past the lock timeout, before maintenance began as apply.database.unavailable, with the suggested action verify_migration_authority, instead of apply.migration.failed. Nothing was changed, so the message says to retry the same apply once the database is reachable rather than to reconcile. The same holds when confirming an already-active package. A failure after maintenance began still reports apply.migration.failed. A reachable database that has never been activated, such as a first apply run without --initial, is not unavailable: it reports apply.package.active_mismatch, whose message now names --initial. See review and apply changes.

bregctl apply treats the already-active package as a no-op, so a repeated deploy exits 0 with activation: already_active and changes nothing. The package is verified in full as the configured active package, and the database must record exactly that package (revision digest, schema fingerprint, sequence, and deployment identity) as active with no maintenance pending; otherwise apply refuses with apply.package.active_mismatch. A different package at the active sequence still refuses. Package binding refusals now report apply.package.binding_mismatch with the differing runtime key as the diagnostic path, such as identity.databaseId or package.activeSequence, instead of the generic apply.package.refused, and never either value. See review and apply changes.

bregctl apply reports a successor refused because retained history coverage does not admit it as apply.history.coverage_incomplete, with the suggested action prepare_history_rebaseline_request, instead of apply.migration.failed. The refusal leaves maintenance state unchanged, and its message names the recovery: finish a pending field-encryption erase-history run or run history rebaseline, then apply the same package again. See retain, erase, and audit.

bregctl apply reports a successor package with nothing to apply as apply.package.empty_plan, with the suggested action correct_package_build, instead of a package binding refusal. See review and apply changes.

Base Registry Engine (BReg) no longer fails an accepted review that the review authority still reports as pending. A 202 from the result resource no longer spends the result-poll attempt budget and clears an earlier result-lookup-uncertain, and the submission recovery deadline no longer ends an accepted review, so an approval that arrives days later is still reconciled and, in automatic mode, applied. Failed lookups and empty 404 answers still exhaust the budget as result-poll-attempts-exhausted, and a 410 still fails the review as result-expired; BReg no longer reports result-recovery-expired. See operate Base Registry Engine.

BReg clears a submission’s recorded error when it reconciles the terminal review result, so the review projection of a settled review reports recovery.state: none instead of operatorAttention for a result lookup that failed before the result arrived. See operate Base Registry Engine.

BREAKING: caseworkctl source add --apply writes one lifecycle hook per paired BReg request entity, casework-lifecycle-v1-<entity>, because BReg requires hook ids to be unique across a registry. The Casework BReg source binding no longer accepts eventType. Remove eventType from each *.breg-runtime.yaml binding and every bare casework-lifecycle-v1 hook from the BReg registry.yaml, then repeat caseworkctl source add --apply. See deploy Registry Casework.

BREAKING: Base Registry Engine (BReg) drops the superseded change-request state, which no transition ever wrote. A request is draft, submitted, cancelled, or applied; the bregState enum in generated OpenAPI and the Rust, Node.js, and Python clients loses the value, and a hook when condition naming superseded no longer compiles. The review result status superseded is unchanged. See change requests.

BReg decides the change-request actions it offers from the settled review result. A rejected request offers only cancel_request. A send-back, or an approval whose availableUntil passed before it was applied, offers revise_request with rebase: false and cancel_request, and no longer offers apply_request. An answered, cancelled, or superseded result keeps revise and cancel but no longer offers apply_request, which it could never pass. BReg refuses the shapes it does not offer: a revise after a rejection, or a rebase after a send-back or an expired approval, answers 409 mutation.conflict. The review projection reports an expired approval as application state expired, including one whose automatic application is queued but not yet applying, which the Rust, Node.js, and Python clients accept, and request lists whose profile discloses review_state can filter on reviewOutcome. The automatic application worker leaves a queued job unclaimed once its cached approval’s availableUntil has passed, rather than spend a retry on a request that no longer offers apply_request. Such a job also no longer holds its review authority or executor binding: the activation check that refuses to drop a binding with durable work outstanding no longer counts it, so an operator may remove a binding an expired, queued job no longer needs. bregctl explain lifecycle reports the check as its review_outcome layer. See change requests.

BREAKING: BReg refuses to compile an access profile with a taskGrant that holds apply_request, with access_profile.task_grant.operation_forbidden. Applying a reviewed request needs a profile of its own without delegated authority; move apply_request there.

BReg no longer contacts the review authority for an apply made under a revoked or expired task grant, whether the caller’s or the one frozen on the proposal: it checks both grants first and records the refused apply in the audit journal. The apply itself was already refused under such a grant, so this closes an early outbound call, not an authorization bypass.

Base Registry Engine (BReg) read permissions can require the subject’s recorded consent with requireConsent. A row reaches a declared recipient organization only while a live give for that recipient, purpose, and profile is recorded; PostgreSQL checks it on every read, and a withdrawal applies to the next request. bregctl module add consent generates the consent records, actions, and profiles for one subject entity. bregctl check reports access.consent.ungated_client for an ungated profile that reads the same rows. Access preview scenarios accept actorKind and requesterClient and report the derived recipients. See require consent for a read and membership and consent read boundaries.

A code added to a BReg field vocabulary is now a compatible additive migration, so it needs no reviewed migration evidence; bregctl diff classifies it lock_or_rewrite_risk because the column check is replaced under a table lock. An action input that starts accepting codes is additive only when each gained code is new to its vocabulary in the same successor. bregctl diff attaches a review reason to consent-related access changes. See change an active registry.

BREAKING: bregctl init --from publicschema and the four BReg starters follow PublicSchema main at commit e5cfbbc, version 0.3.0. The agricultural-holdings starter takes PublicSchema’s agricultural holder names: its *-holding-operator-role entities and routes become *-agricultural-holder-role, and the operatedHolding and holdingOperator* fields become holderFarm and holderPerson, holderOrganization, or holderGroup. A project copied from that starter keeps working as written; initialize it again to take the new names, which come without a data migration. The seed-lots starter aligns its fields to renamed PublicSchema concepts. PublicSchema retired public_mandate, so the public-organizations starter aligns its free-text description field to PublicSchema’s description instead. Neither starter changes a field, route, or record. PublicSchema defines end_date as the last day a period applies, so a period includes its end date. See derive a registry from PublicSchema.

A --selection document for bregctl init --from publicschema may now name a modelRevision alongside modelVersion. PublicSchema can keep one version label across structurally different revisions, so modelVersion alone does not pin one; modelRevision pins the upstream commit the embedded snapshot was copied from, and init refuses a selection naming a different one. The wizard, the household starter selection, and the Evidence tutorial’s selection write it, and the generated README’s attribution section states it beside the version. See derive a registry from PublicSchema.

v0.33.0 beta-45

Registry Scheduling joins the release with published openings, exact-time offerings, arrival windows, holds, and accountable appointments. Each commitment requires a task grant bounded to the offering’s service, location, and action. The release publishes a Scheduling container image, without a binary or installer asset. See the Registry Scheduling API.

BREAKING: Registry Casework replaces hosted decisions with source-neutral review requests, tasks, kinds, results, and accountability. Base Registry Engine (BReg) delegates governed change-request review to Casework through a review authority binding. The Casework migration drops the experimental hosted tables without carrying their data forward. See review BReg changes in Casework.

BREAKING: BReg entity events are now shared hooks, and deliveries carry a signed hook envelope instead of the earlier bare body. Rewrite each entity declaration, drain the existing outbox before upgrading, update receivers, and regenerate project locks. BReg now requires PostgreSQL 17 or newer.

BReg ships WebAssembly action handlers enabled by default, field encryption for restricted fields, and durable resumable ingestion runs. Existing Rhai and declarative action handlers keep working. See field encryption for restricted fields and the BReg client capabilities.

Registry Render is available from source with offline CLI, HTTP service, and Rust library modes for deterministic Typst PDF rendering. v0.33.0 does not publish a Render release asset or container image. See the Registry Render overview.

Evidence tooling adds machine-readable reports, an offline-complete starter, and self-checking local target generation. Object answer schemas must now declare properties and additionalProperties: false.

The BReg clients expose typed applied-request results and durable ingestion runs. bregctl explain and caseworkctl machine-readable output now use versioned, closed JSON report contracts.

v0.32.0 beta-44

Exchanged access tokens carry registry_assertion_issuer, derived from the verified subject-token issuer. Evidence, Base Registry Engine (BReg), and Casework can pair each client with the assertion issuers it may present and refuse any other. Without that configuration no pairing rule applies.

BReg governed request application can re-check fresh Evidence and linked-record preconditions at Apply, and BReg Evidence providers can use privateKeyJwt to refresh credentials instead of a static tokenRef. See operate Base Registry Engine.

Evidence questions can answer with a governed bounded-identifier value. The Rust, Node.js, and Python Evidence clients can authenticate through token exchange, and the BReg, Relay, and Casework clients can obtain person- or task-grant-bound exchanged tokens. See disclosure modes and computed answers and the client API.

Local development can compose BReg, Evidence, and Casework under one shared issuer. evidencectl access client add adds task-grant and first-party exchange modes, and bregctl examples run runs the scenarios a project authors in examples/scenarios.json. See evidencectl.

Local ThunderID development containers are now named per state root. After upgrading, remove a container started by v0.31.0 once with docker rm -f thunderid-<label>-<id prefix> and start the session again. Retained state is untouched.

v0.31.0 beta-43

Registry Mint retired; the mint config key and retired CLI flags are refused.

Grant authority removed: Base Registry Engine (BReg) taskGrant.authority and task status client authority, Casework taskAuthority.id, and Evidence’s grantAuthority claim name. BReg status clients are keyed by source issuer only.

Casework task assertions no longer carry registry_grant_authority or registry_grant_source_issuer; ThunderID derives the source issuer from the verified iss.

Local dev databases holding grants or drafts from before #1044 no longer load; reset local dev state.

@registrystack/client exposes breg.verifyWebhookDelivery() for Node receivers. The helper delegates the Version 1 signature contract to the shared Rust verifier and returns the authenticated CloudEvents attributes, delivery metadata, and exact body. Receivers still bound clock skew, validate the expected event contract, and deduplicate before applying an effect. See verify a webhook delivery.

v0.30.0 beta-42

Registry Casework ships with Registry Stack 0.30.0 and has a documentation set of its own: an overview, the decide your first work item tutorial that a CI gate replays, how Casework works, author a Casework policy, deploy Registry Casework, retain, erase, and settle, the API contract, and a Casework section in the client API reference. The installer casework-install.sh installs casework and caseworkctl, and caseworkctl dev start starts a retained local runtime with its PostgreSQL container, pinned stock issuer, and seeded directory.

Registry Casework names the failing secret reference and the rule it broke when a database, audit, or static JWKS secret cannot be resolved, without echoing the value; the operator file accepts authentication.oidc.jwksSource: {kind: static, documentRef: …} beside issuer discovery; and the two work-item history routes are documented separately: hosted-history for hosted work and history for source-scoped reads under Registry-Source-Profile. See deploy Registry Casework.

Base Registry Engine warns about unknown or disallowed access-token key identifiers in its JSON log messages, at most once per minute per authenticator. Caller refusals remain value-free. The warning does not establish provider key rotation. The operations guide describes how to confirm rotation and replace a static documentRef pin supplied by either a file or an environment variable. Automated coverage verifies authentication refusal, bounded diagnostics, and recovery after replacing an in-memory key set; it does not execute the operational runbook. See operating Base Registry Engine.

The Base Registry Engine access-token verifier admits both RFC 9068 spellings of the access-token media type as one configured token type: accessTokenType: at+jwt and accessTokenType: application/at+jwt each accept tokens whose typ header carries either spelling. All typ matching remains case-insensitive, and values outside the configured token type are still refused. An issuer can switch between the two permitted spellings without an engine configuration change. ThunderID emits at+jwt, while other providers may emit the full media type. See operating Base Registry Engine.

GET /v1/registry lists each operation’s readableRequestFields beside readableFields, so a caller can learn before a read whether its selected profile receives request review state, actor references, or decision reasons. The list follows the rule request reads apply: an anonymous profile, or an entity without a change request, lists no request fields. See Base Registry Engine API.

The Rust, Node.js, and Python Base Registry Engine clients accept the action.refused problem an immediate action answers a declared business rule with. No client registered that code, so the one refusal a caller is meant to act on arrived as an opaque protocol failure. The typed error carries the package-declared reason as refusal_code in Rust and Python and refusalCode in Node.js, beside the status, the code, and the trace identifier, and the catalogue label stays in the detail. A reason outside the published bounds, a missing one, or one attached to any other code fails closed. See client API reference.

The published problem-code table documents action.evidence_failed, the 503 an immediate action answers when a declared Evidence dependency could not be acquired or accepted. The engine registers the code and answers with it, and the table named every other one. See Base Registry Engine API.

readableRequestFields widens to review_state and actor_reference, disclosing review, reviewTiming, submitterReference, and applierReference on a change-request record for a non-anonymous profile. Every change-request action response now also includes actorReference, independent of readableRequestFields. See Base Registry Engine API.

v0.29.0 beta-41

BREAKING: request-lifecycle webhook bodies add required request.reasonPresent and optional request.reason. Update strict receiver schemas before activating this release. Deliveries that can match rejection or revision now need a destination classificationCeiling of at least internal, or lifecycle filters that exclude both outcomes. See Base Registry Engine API and deliver declared events.

Base Registry Engine adds governed request attachment slots, PostgreSQL or operator-bound S3 storage, and asynchronous external verification. Select storage and verification before the first upload, which pins both bindings. Request-detail erasure now includes attachment references; external cleanup retries remain an operator responsibility. See runtime configuration and retain, erase, and audit.
Reject and request-revision actions accept an optional explanation. Request grants default to showing retained reason text; set readableRequestFields to [] to hide it. Current and retained proposal decisions follow the selected profile’s authority. See Base Registry Engine API.
bregctl dev events inspects receipts from the local webhook receiver, with captured values available only through --include-payload. See deliver declared events.

bregctl dev reports the check that refused a start instead of only the private log directory. The rehearsal, package build, activation, and verification run inside a detached supervisor, so a refused journey step now reaches your terminal with its code, its journeys[i].steps[j] path, and its own message. See author journeys.
bregctl dev start compares the breg it resolved against its own version before it starts anything, and refuses a binary from another release by name, giving both versions and the fix. The issuer runs from the pinned stock image. Previously a binary mismatch surfaced much later as a refused package or an unready database.
A refused fixture logical reference names its class: a field the entity does not declare, a field the access profile grant does not make writable, a request body with no field, a step identifier that is not stable, a step naming both an entity and an action or neither, or a capture no earlier step declares. The sentence still carries no authored value.

bregctl check no longer tells you to drop a row boundary field from writableFields on a grant that also creates. The boundary compiles to an INSERT WITH CHECK pinning that field to the caller’s claim, so the field has to stay writable and each create has to send a value the claim allows. access.profile.writable_row_boundary now words its advice for the grant’s operations, the new access.profile.row_boundary_not_writable reports a create whose boundary field is not writable, and bregctl test names the row boundary rather than reporting an anonymous reference refusal. See control access per profile.

The Rust, Node.js, and Python Base Registry Engine clients select governed request attachment slots from caller-filtered registry metadata and run the upload, download, and delete exchanges. A slot carries the served size limit, the accepted content types, and the route authority, so an empty body, an oversize body, or an unaccepted media type refuses before any request. Raise the client’s maximum response bytes when a slot serves more than the 8 MiB default read bound. See client API reference.

A request attachment slot serves the classification its registry configuration authored. It travels in the x-registry-attachment extension, so it reaches /v1/registry and the caller-filtered OpenAPI document under the same filtering as the size bound and the accepted content types, and the Rust, Node.js, and Python clients read it off the selected slot. A caller can now tell restricted slot content from public before downloading any bytes. The value is advisory: it grants and withholds no route. See Base Registry Engine API.

The attachment download operation sends the bare attachment disposition in Content-Disposition. No stored slot metadata holds a filename, and the served OpenAPI document pins the header to that exact value. Callers choose their own filename when saving the bytes. See Base Registry Engine API.

v0.28.0 beta-40

BREAKING: bregctl dev and bregctl dev stop take a positional project directory. Replace --project <dir> with <dir> in scripts. Both commands still default to the current directory. See create and query your first registry.
Base Registry Engine supports bounded Rhai action handlers, linked-target acceptance checks, native persisted-field patterns, and membership read boundaries. Test new patterns against PostgreSQL before packaging; adding a pattern validates existing rows under a table lock, and changing or removing one requires a reviewed migration. See governed registry actions, native field patterns, and membership read boundaries.
The trial action-handler ABI version 2 resolves declared, verified Evidence Gateway assertions with operator-bound providers. Accepted assertion material has a separate 24-hour retention period. Use bregctl evidence-retention erase-expired to erase expired assertion bytes and verification context while keeping receipts replayable. See retain, erase, and audit.

submitterTargets can require current same-profile GET authority over the native-reference targets of a manually applied change request, including on exact replay. Request lists expose authorized filtering and sorting on bregState, proposalVersion, and effectDigest; ordinary field API names cannot reuse those names. Structured fields also accept an array schema root with declared items. See declare change requests and actions.
The unified Node.js client’s Base Registry Engine namespace adds exact-JSON metadata, record, and lifecycle methods. Serialized JSON avoids silent rounding at the JavaScript number boundary, and unsupported values refuse. Keep exact values as JSON text or use a lossless decoder.

bregctl init --from publicschema derives a project from the embedded model through a wizard, selection file, or starter. Four starter projects include local examples that can resume or restart. Projects copied from the unreleased professional-licences starter must be initialized again because its correction fields changed without a migration path. See derive a registry from PublicSchema.
evidencectl source add previews a connection from a stopped local registry and performs it with --apply, preserving records, revisions, and client identities. It requires a matching-version bregctl on PATH. See the evidencectl workflow reference.
Registry Manifest refuses duplicate concept terms on a field after IRI expansion and scheme/host case comparison. Remove repeated entries before validating or republishing. Valid manifests retain their authored spelling and source digest. See contracts.

Export, migration, local development, and Compose preflight failures report clearer recovery information. Evidence authoring validates source origins and runtime settings consistently with deployment checks, and bounds child diagnostics and version handshakes. See the evidencectl workflow reference and change an active registry.
Release checksums now include SLSA build provenance for the publication workflow that assembles SHA256SUMS; candidate evidence retains the binding to payload builds. See OpenSSF and release trust.
CLI reference pages and generated reference data are built from reviewed source inputs during the documentation build.

Documentation present in v0.27.0

Clarified that Discovery selection validation checks closed structure and capability binding, not trust or currentness, and kept the compatibility aliases for existing Node.js and Python adopters. The Rust crate renamed validate_service_selection to validate_service_selection_structure with no alias, because the crate is unpublished and exempt from the compatibility promise.
Added the adopter-owned accepted-service handoff and explicit online renewal workflow. Credentials and native Evidence or Relay input and output remain outside Discovery and follow local acceptance.
Documented Base Registry Engine from its released installer, binaries, and container image instead of a build from a checkout.
Pinned the Base Registry Engine tutorial checkouts to the installed version and documented the --installed mode of the quickstart and demo launchers.

2026-08-20

Documentation prepared for the v0.23.0 beta-34 release:

Documented Registry Discovery: the curated, read-only index of public Evidence and Relay service descriptions, the closed registry-discovery-v1alpha1 provider profile, the bounded relying-party search and ambiguity-safe selection, and the discoveryctl operator flow.
Documented that a Discovery selection is inert public metadata, not a trust decision and not a native request.
Documented the npm and PyPI distribution of the Registry Discovery client package alongside the existing Evidence and Relay clients.
Documented the progressive Evidence client API across the Node and Python bindings and the synchronized client tutorial paths.
Documented relayctl’s human-readable default output and the unchanged --json report document.
Reorganized the sidebar by what a reader came to do, published two tutorials, and retired the duplicate chooser page.
Rewrote the style guide for readers rather than runners, and stopped printing values a reader cannot reproduce, such as compiled contract revisions and installation-dependent counts.
Added the v0.23.0 beta-34 candidate documentation archive.

2026-08-14

Documentation prepared for the v0.22.0 beta-33 release:

Documented the explicit container-private Evidence listener mode, native Evidence, Mint, and Relay deployment checks, and the common Compose runtime preflight.
Documented Relay issuer identity independently from OIDC discovery or direct JWKS transport while preserving canonical discovery compatibility.
Added Registry Mint’s opt-in client-secret profile for managed standard OAuth clients, while retaining private_key_jwt as the default and sole method for Evidence and delegated authority.
Added owner-only client-secret provisioning, per-installation registration, bounded rotation and revocation guidance, and a QGIS Client Credentials walkthrough. The walkthrough is configuration guidance, not release-gate interoperability evidence.
Documented the npm and PyPI distribution transaction for the exact checksum-covered Evidence and Relay client packages. Registry publication is accepted only when registry digests match the candidate bytes.
Documented that the Relay installer verifies and installs matching relay and relayctl binaries together on Linux amd64 and preserves the previous pair on failure.
Documented eager Evidence trusted-key validation, Mint’s reserved scope authority boundary, categorical Relay editor diagnostics, and governed-only Relay project indexing.
Hardened synchronized product documentation so it is compiled as inert Markdown and refuses active raw HTML or unsafe rendered destinations.
Added the v0.22.0 beta-33 candidate documentation archive.

2026-08-13

Documentation updates for the v0.21.0 beta-32 release:

Documented the official Evidence Gateway and Registry Mint runtime images alongside the existing Registry Relay image.
Distinguished the source-build definitions under docker/ from the reviewed release-image definitions under release/docker/.
Documented operator-mounted configuration, governed packages, secrets, keys, and audit storage for all three runtime images.
Added the v0.21.0 candidate documentation archive.

2026-08-12

Documentation updates for the v0.20.1 beta-31 patch release:

Documented Evidence HTTP sources that treat one exact governed 404 Problem Details response as a neutral unresolved consultation instead of a source failure.
Documented the data-free declaredUnresolved: true fixture case and the fail-closed behavior for malformed, undeclared, or mismatched responses.
Added the v0.20.1 candidate documentation archive. Registry Mint and Relay V2 behavior are unchanged from v0.20.0.

Documentation updates for the v0.20.0 beta-30 release:

BREAKING: Made holderBoundBatchMaxSize a required member of the registry.evidence-definitions/v1 metadata response.
Upgrade the Evidence runtime, Evidence clients, and Evidence OID4VCI adapter together. New clients read an older response without this member as a batch size of 1; older strict clients reject responses that contain the new member.
BREAKING: Removed the reserved registry_relay vocabulary prefix from registry-manifest/v1. Use absolute IRIs or declare an institution-owned active vocabulary before validating and republishing affected metadata.
Documented the first prebuilt Relay Node.js and Python client packages, which are attached to the matching GitHub Release rather than published to npm or PyPI.
Added the v0.20.0 candidate documentation archive and advanced maintained release, installation, contract, and standards references to v0.20.0.
Added generated command references for the current CLIs, Relay V2 editor support, complete OID4VCI delivery guidance, and Evidence local source API mock guidance.
Removed the remaining Relay V1 and registryctl source references from the current product surface while retaining their v0.19.0 retirement record.

2026-08-11

Documentation updates for the v0.19.0 beta-29 release, which replaced both Relay identities:

BREAKING: relay replaces the registry-relay runtime, and relayctl replaces registryctl. The legacy runtime, the Rhai worker, the registryctl binary, its installer, its image lock, and the PostgreSQL release closure are absent from the release.
Rewrote the Relay documentation around the V2 model: a governed registry contract, a deployment-local runtime document, and generated package artifacts. Relay V1 configuration is not an in-place upgrade input.
Documented the V2 read surface: bounded Record reads, named lookups and searches, CRS84 Point data as GeoJSON or JSON-FG, and a profiled SDMX data and structure read subset. Access profiles stay independent of wire-format selection.
Removed the documentation for capabilities V2 does not implement: spreadsheet, HTTP, and PostgreSQL sources, Rhai script adapters, API-key and OAuth client-credentials authentication, the two-lane public and consultation split, materialization, and the administrative posture endpoint. Known limitations records what is now absent.
Replaced the pinned Relay OpenAPI reference with the per-deployment model. Relay V2 generates its description from the adopter’s registry contract and serves it at GET /openapi.json.
Removed the generated authoring reference and diagnostic catalogs, which were produced from registryctl introspection commands that relayctl does not yet offer.
Rewrote the normative RS-* specifications for the Relay protocol, adopter tooling, operational posture, security, and terminology against the V2 contracts.
Recorded the Relay V1 and registryctl retirement decision and redirected the retired routes.
Documented the Relay installer and the ghcr.io/registrystack/relay:v0.19.0 image. relayctl has no installer; it is taken from the release assets or built from source.
Documented the Evidence bounded multi-subject request batch, which shares one authorization and execution budget and returns results in request order. Existing single-subject clients need no wire-format migration.
A Registry Docs archive is not part of this release, so the current documentation can be updated without waiting for a runtime release.

2026-08-09

Documentation updates for the v0.18.0 beta-28 release candidate:

Added holder-bound Evidence issuance, bounded atomic batches, and presentation verification with RFC 9901 key-binding JWTs.
Added the Evidence OID4VCI 1.0 Final wallet-delivery adapter, including its protected offer flow, proof validation, single-replica constraint, and bounded in-memory lifecycle.
Documented reviewed immutable SQLite extraction, fixed multi-stage source acquisition, and private-key-JWT source authentication.
Added the evidence-oid4vci binary to the Evidence installer and release inventory for all three supported platforms.
Added the v0.18.0 candidate documentation archive.

2026-08-07

Documentation updates for the v0.17.0 beta-27 release candidate:

Added the Evidence runtime, adopter tooling, relying-party client, portable verifier, and Registry Mint supporting service to the maintained product documentation.
Added Evidence tutorials and operator guidance for fixed source acquisition, authorization, minimum-disclosure output, signing, key rotation, audit, and relying-party verification.
Retired Registry Notary from the current product and release surfaces while preserving historical release records.
Documented Relay scalar-only attribute-release claims and the warning for aggregate routes without a longitudinal privacy budget.
Added the v0.17.0 candidate archive and the stable Registryctl installer served from the exact promoted documentation archive.
Recorded Node and Python Evidence client packages as GitHub Release assets, without npm or PyPI publication.

2026-08-03

Product direction update:

Recorded the decision to retire Registry Notary from the current product surface while preserving historical changelogs, decision records, and release manifests.
Reframed the supported product paths around Registry Relay for scoped, protected reads and Evidence for minimum-disclosure assertions.
Kept Evidence independent from the retired Notary product model, with Registry Mint limited to supporting token issuance.

Adopter-facing breaking change:

Raised the registryctl approved-set schema to version 2.0 and made registryctl refuse an approved set issued before the retirement, including a version 1.0 document, a set carrying a notary lane, and a set binding cross-lane interface digests.
Required affected deployments to re-approve their baseline from the current lane bundles, because the removed cross-lane interface digests are no longer verified and the old approval’s integrity claim is no longer enforced. See Approve the initial product baseline.

2026-08-01

Stabilization updates for the v0.16.3 beta-26 release candidate:

Recorded that v0.16.2 stopped after staging an unpublished draft and before public image or documentation publication.
Added the v0.16.3 candidate archive and retained v0.16.0 through v0.16.2 as failed-train records.
Simplified Beta publication recovery without changing product behavior.

Fix-forward updates for the v0.16.2 beta-25 release candidate:

Recorded that the immutable v0.16.1 tag workflow stopped after creating an unpublished empty draft GitHub Release.
Recorded that v0.16.1 has no public release, final images, assets, or documentation, and directed adopters to install only v0.16.2.
Added the candidate v0.16.2 archive while retaining the v0.16.0 and v0.16.1 failed-train records and v0.15.2 as the latest published release.

Fix-forward updates for the v0.16.1 beta-24 release candidate:

Recorded that the immutable v0.16.0 tag workflow failed during startup before any job or public write.
Recorded that v0.16.0 has no GitHub Release, final images, assets, or documentation, and directed adopters to install only v0.16.1.
Added the candidate v0.16.1 archive while retaining the v0.16.0 candidate history and v0.15.2 as the latest published release.

Documentation updates for the v0.16.0 beta-23 release candidate:

Added the maintained spreadsheet and HTTP adopter journeys, including the common authoring, test, development, build, trust, and deployment workflow.
Documented separate public and consultation Relay lanes, signed artifact roots, persistent audit records, and strict public Relay client validation.
Documented Relay sensitive-read gates, snapshot recovery, no-expiry OAuth migration, and Script budget accounting.
Documented Notary’s registry-backed evidence requirement, structured claims, registrar offers, representative issuance, delegated-target enforcement, expiry rechecking, and state-catalog upgrade procedure.
Added the candidate v0.16.0 archive while retaining v0.15.2 as the latest published release until promotion completes.

2026-07-28

Fix-forward updates for the v0.15.2 beta-22 release:

Recorded the immutable partial v0.15.1 publication and moved forward without reusing its tag or public image names.
Bound capsule validation to the exact same-digest candidate-to-public Registry Stack image mappings.
Made observational promotion telemetry nonblocking and removed its obsolete fixed measurement count.

Fix-forward updates for the v0.15.1 beta-21 release candidate:

Preserved the immutable failed v0.15.0 tag and recorded that its workflow stopped before any public release or image publication.
Corrected exact annotated-tag binding extraction without weakening the closed candidate-binding parser.
Prepared the v0.15.1 candidate docset while retaining the failed v0.15.0 candidate archive and v0.13.0 as the latest published release.

Documentation updates for the v0.15.0 beta-20 release candidate:

Published the versioned Registryctl installer and the spreadsheet-first local API and registry-backed claim tutorials as the maintained beginner path.
Added generated configuration, ownership, authoring, fixture, and operator references for the complete project-authoring surface.
Documented all-row spreadsheet validation, stable governed attribute release, Relay-to-Notary consultation closure, and value-free activation diagnostics.
Added the candidate v0.15.0 archive while retaining v0.13.0 as the latest published release until promotion completes.
Recorded that v0.14.0 was not published and is not part of this release lineage.
Kept Solmara, hosted publication, external OpenID, OpenCRVS, DHIS2, wallet, verifier, and country-acceptance evidence as separate gates.

2026-07-26

Unreleased current-source documentation updates:

Added task-oriented Start, Connect your data, Operate, Security, and Reference navigation for new adopters.
Added generated references for all five authored and both runtime configuration domains, with fail-closed field-intent and ownership coverage.
Added separate generated authoring, fixture, and operator diagnostic references.
Restored the released spreadsheet API and live registry-backed claim tutorials as the primary beginner path.
Kept advanced operations for rotation, materialization, reapproval, diagnosis, Script workers, recovery, upgrade, migration, and rollback available from the operator handoff instead of presenting them as beginner journeys.

These pages describe the current source under test. They are not part of the immutable v0.13.0 archive and do not claim candidate, hosted, country, interoperability, or production evidence.

2026-07-25

Documentation updates for the v0.13.0 beta-17 release:

Advanced current source citations, install commands, verification examples, contracts, projects, and standards links to Registry Stack v0.13.0.
Added the v0.13.0 archived docset while retaining every earlier release archive.
Documented removal of Relay’s inert provenance.consent result member, the required pre-release consultation-state re-bootstrap, and Notary’s matching closed decoder.
Documented the shared deployment-waiver reference and optional summary contract, with the retired reason field rejected.
Updated Registryctl authoring examples to keep source adaptation, evidence policy, and consumer decisions separate, and recorded the registryctl.smoke.v1 report schema.
Kept Solmara, hosted publication, external integration, OpenID, lifecycle, OpenSPP holdout, and pilot evidence as separate held gates.

2026-07-23

Made the Relay-to-Notary-to-evidence-consumer responsibility boundary normative for 1.0 project authoring. Updated Notary guidance and registryctl examples to keep reusable evidence separate from consumer-owned requirements, decisions, workflow, and action rules.

2026-07-20

Documentation updates for the v0.12.2 beta-16 fix-forward release:

Advanced current source citations, install commands, verification examples, contracts, projects, and standards links to Registry Stack v0.12.2.
Added the v0.12.2 archived docset while retaining the incomplete v0.12.0 and v0.12.1 publication records and every earlier archive.
Recorded separate Registryctl and Relay release builds, verification of the shipped Relay feature set, and pinned canonical binary and image wrappers used to reproduce candidate hashes and ordered runtime root filesystem layers.
Recorded Relay’s move to quick-xml 0.41 and the exact ryu-js 1.0.3 pin, retiring temporary dependency exceptions without adding product features.
Moved Registry Notary router tests to in-process transport where network semantics are not under test, preventing release-gate socket exhaustion without changing production request handling.
Recorded the production fix that isolates each single-use eSignet authorization-code exchange on short-lived DNS-pinned transport, with redirects and proxies denied, bounded timeouts, and no transparent retry.
Kept Solmara, hosted publication, external integration, OpenID, lifecycle, and pilot evidence held.

Documentation updates for the v0.12.1 beta-15 fix-forward release:

Advanced current source citations, install commands, verification examples, contracts, projects, and standards links to Registry Stack v0.12.1.
Added the v0.12.1 archived docset while retaining the incomplete v0.12.0 publication record and every earlier archive.
Recorded the root-filesystem-bound reviews for the three non-fixable Debian 13 libc6 findings that stopped the v0.12.0 publication attempt.
Recorded deterministic release plans, remote tag checks, both-image Open Containers Initiative label smoke, and safer release workflow routing.
Kept Solmara, hosted publication, external integration, OpenID, lifecycle, and pilot evidence held.

2026-07-19

Documentation updates for the v0.12.0 beta-14 release:

Advanced current source citations, install commands, verification examples, contracts, projects, and standards links to Registry Stack v0.12.0.
Added the v0.12.0 archived docset while retaining the v0.11.0 and earlier archives.
Documented Registry Notary’s issuer-initiated pre-authorized-code profile, bounded batch evaluation, generated runtime configuration schema, and fail-closed credential-status verification.
Documented Registry Relay’s intended 1.0 support roster and protected per-resource last-good refresh health.
Updated Registryctl tutorials for human-readable report defaults and the matching v0.12.0 binary, image lock, and image generation.
Recorded the Debian 13 runtime transition and kept candidate-only lifecycle, external integration, OpenID, Solmara, hosted, and pilot evidence held.
Documented Relay’s protected per-resource refresh-health metrics, restricted posture observation, last-good availability behavior, and default alert at three consecutive failures.
Documented the source installer for the optional VS Code and Zed semantic-navigation integrations. Editor installation is user- or profile-scoped and remains separate from project-local schema setup through registryctl init or registryctl authoring editor.

2026-07-18

Documentation updates for the v0.11.0 beta-13 release:

Advanced current source citations, install commands, verification examples, contracts, projects, and standards links to Registry Stack v0.11.0.
Added the v0.11.0 archived docset while retaining the v0.10.0 and earlier archives. The public release inventory remains eight artifacts. Registryctl embeds the optional preview language server; it is not a separate release artifact. The VS Code and Zed extensions remain source-installed developer previews and are not marketplace packages.
Published the registry-backed local Notary tutorial and the maintained authoring-workspace catalog. Registryctl continues to expose exactly five public starters. The local tutorial proves evaluation only, not credential, wallet, presentation, or OID4VCI interoperability.
Documented the credential-issuance migration: only fresh, non-delegated, registry-backed evaluations with exact Relay provenance are credential capable. Source-free and delegated results remain evaluation and rendering surfaces, and old evaluations require re-evaluation before issuance. No database migration is required solely for this narrowing.
Added migration coverage for ambiguous primary credentials, strict empty environment expansion, Relay Script host-call diagnostics, and offline audit quarantine recovery.

This beta does not claim stable 1.0 completion, full OID4VCI interoperability, hosted promotion, audit completion, or an external pilot result.

2026-07-16

Documentation updates for the v0.10.0 beta-12 release:

Advanced current source citations, install commands, and deployment examples to Registry Stack v0.10.0.
Added the v0.10.0 archived docset with the four formal products and Crosswalk. Solmara Lab remains a separate adopter demo, not a released Registry Stack artifact.
Published the Notary PostgreSQL install, role, migration, retention, backup, restore, recovery, supported-version, restart, and multi-instance contract.
Added separate Relay consultation-state backup and restore guidance without sharing Relay roles, schemas, or tables with Notary.
Replaced the retired monorepo Lab documentation route with a source-backed Solmara local journey.

Migration notes:

Notary production correctness state now uses Notary-owned PostgreSQL. The pre-1.0 Redis cutover is a stopped-writer transition with explicit drain and credential-status gates.
Registry project authoring now uses registry-stack.yaml, explicit integrations, fixtures, service topologies, and environment bindings. Reauthor pre-1.0 project files and review changed RFC 8785 canonical digests before signing.
Deploy one Notary authority per Relay trust domain. Identical replicas may share that authority’s Notary database, but Relay and Notary retain separate state ownership.
Deploy the released Relay Rhai and Notary CEL workers only for their owning product’s adapter contract. They are not a shared extension or state framework.

2026-07-10

Documentation updates for the v0.9.0 beta-11 release:

Advanced the active monorepo docs and source citations to RegistryStack v0.9.0.
Added the v0.9.0 archived docset pinned to the beta-11 freeze source ref.
Updated registryctl install examples and current deployment tutorials to the v0.9.0 release tag while retaining the published v0.8.4 stale-digest workaround until tagged artifact proof closes it.
Kept hosted first-run publication held while the credential failure in GH#330 and the complete GH#198 fresh-reader run remain open.

Migration notes:

Registryctl project generation now requires the strict image lock from the same release beside the binary, or at an explicitly verified REGISTRYCTL_IMAGE_LOCK path. Existing projects still run from their stored immutable pins. See GH#339.
Relay passes a client-supplied trust-context header to the PDP only when the caller has the exact registry:trust:<field>:<value> scope. Update caller scopes before relying on those fields; their value-bearing audit scopes are now pseudonymized. See GH#338.
Notary federation denials now preserve their audit context. No new client request field is required, but operators should retain the enriched denial records. See GH#337.

2026-07-04

Documentation updates for the v0.8.4 beta-10 release:

Advanced the active monorepo docs and source citations to RegistryStack v0.8.4.
Added the v0.8.4 archived docset pinned to the beta-10 source ref.
Updated registryctl install examples and current deployment tutorials to the v0.8.4 release tag.
Recorded v0.8.3 as the first provenance-bearing root release.

2026-06-26

Documentation updates for the v0.8.3 security and release-trust patch:

Advanced the active monorepo docs and source citations to RegistryStack v0.8.3.
Added the v0.8.3 archived docset pinned to the beta-9 source ref.
Updated registryctl install examples to the v0.8.3 release tag.
The v0.8.2 docset remains archived; its release carries no tag-bound SLSA provenance.

2026-06-25

Documentation updates for the v0.8.2 fix-forward release:

Advanced the active monorepo docs and source citations to RegistryStack v0.8.2.
Added the v0.8.2 archived docset pinned to the beta-8 source ref.
Updated registryctl install examples to the v0.8.2 release tag.
Kept the v0.8.1 docset archived (source tag only; no release artifacts were published).

Documentation updates for the v0.8.1 source release:

Advanced the active monorepo docs and source citations to RegistryStack v0.8.1.
Added the v0.8.1 archived docset pinned to the beta-7 source ref.
Added monorepo-aware archive handling for v0.8.x docsets while keeping older beta archives on their legacy source repos.
Updated registryctl install examples to the v0.8.1 release tag.

2026-06-24

Documentation updates for the beta-5 source release:

Added the Beta 5 docset with pinned refs for Platform, Manifest, Notary, Relay, Lab, registryctl, Crosswalk, and Atlas as a Lab input.
Advanced the active product docs to Registry Relay v0.5.0, Registry Notary v0.7.0, and Registry Manifest v0.2.2.
Updated OpenCRVS, FHIR-adjacent, and standalone deployment tutorial references to the beta-5 release pins.

2026-06-22

Documentation updates for the beta-4 source release:

Added the Beta 4 docset with pinned refs for Platform, Manifest, Notary, Relay, Lab, registryctl, Crosswalk, and Atlas as a Lab input.
Advanced the active product docs to Registry Relay v0.4.1, Registry Notary v0.6.2, and Registry Manifest v0.2.2.
Updated source citations and tutorial install commands to beta-4 refs.

2026-06-21

Documentation updates for the beta-3 release candidate:

Added the Beta 3 docset with pinned candidate refs for Platform, Manifest, Notary, Relay, Lab, registryctl, Crosswalk, and Atlas as a Lab input.
Re-pinned repo-doc imports, source links, and registryctl installer paths away from mutable main URLs.
Added OpenCRVS and FHIR tutorial coverage for beta-3.

2026-06-20

Documentation updates published:

A scannable homepage section index to orient new visitors.
Dark mode with a theme toggle.
Outcome-first tutorials with prerequisites and numbered steps.
New reference pages for the registryctl CLI, error and status codes, and environment variables.
A native, searchable, theme-aware API reference.
A per-page footer showing the last-reviewed date, an edit link, and a feedback control.

2026-06-13

Documentation set: the Latest docset published from the main branch, tracking main snapshots of Registry Relay, Registry Notary, and Registry Manifest.

2026-06-12

Documentation set: the Beta 2026-06-12 docset frozen and archived, covering the following product versions.

Product	Version
Registry Notary	v0.3.0
Registry Relay	v0.2.0
Registry Manifest	v0.2.0
registryctl	v0.1.0
Registry Platform	v0.2.1
Crosswalk	crosswalk-core-v0.2.0