Unreleased documentation. These pages follow the main branch and can change before the next release. For supported guidance, use v0.26.1.
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
Section titled “Unreleased”v0.32.0 beta-44
Section titled “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
privateKeyJwtto refresh credentials instead of a statictokenRef. See operate Base Registry Engine.
- Evidence questions can answer with a governed
bounded-identifiervalue. 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 addadds task-grant and first-party exchange modes, andbregctl examples runruns the scenarios a project authors inexamples/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
Section titled “v0.31.0 beta-43”- Registry Mint retired; the
mintconfig key and retired CLI flags are refused.
- Grant authority removed: Base Registry Engine (BReg)
taskGrant.authorityand task status clientauthority, CaseworktaskAuthority.id, and Evidence’sgrantAuthorityclaim name. BReg status clients are keyed by source issuer only.
- Casework task assertions no longer carry
registry_grant_authorityorregistry_grant_source_issuer; ThunderID derives the source issuer from the verifiediss.
- Local dev databases holding grants or drafts from before #1044 no longer load; reset local dev state.
@registrystack/clientexposesbreg.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
Section titled “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.shinstallscaseworkandcaseworkctl, andcaseworkctl dev startstarts 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-historyfor hosted work andhistoryfor source-scoped reads underRegistry-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
documentRefpin 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+jwtandaccessTokenType: application/at+jwteach accept tokens whosetypheader carries either spelling. Alltypmatching 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 emitsat+jwt, while other providers may emit the full media type. See operating Base Registry Engine.
GET /v1/registrylists each operation’sreadableRequestFieldsbesidereadableFields, 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.refusedproblem 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 asrefusal_codein Rust and Python andrefusalCodein 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.
readableRequestFieldswidens toreview_stateandactor_reference, disclosingreview,reviewTiming,submitterReference, andapplierReferenceon a change-request record for a non-anonymous profile. Every change-request action response now also includesactorReference, independent ofreadableRequestFields. See Base Registry Engine API.
v0.29.0 beta-41
Section titled “v0.29.0 beta-41”- BREAKING: request-lifecycle webhook bodies add required
request.reasonPresentand optionalrequest.reason. Update strict receiver schemas before activating this release. Deliveries that can match rejection or revision now need a destinationclassificationCeilingof at leastinternal, 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
readableRequestFieldsto[]to hide it. Current and retained proposal decisions follow the selected profile’s authority. See Base Registry Engine API. bregctl dev eventsinspects receipts from the local webhook receiver, with captured values available only through--include-payload. See deliver declared events.
bregctl devreports 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, itsjourneys[i].steps[j]path, and its own message. See author journeys.bregctl dev startcompares thebregit 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 checkno longer tells you to drop a row boundary field fromwritableFieldson a grant that also creates. The boundary compiles to an INSERTWITH CHECKpinning 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_boundarynow words its advice for the grant’s operations, the newaccess.profile.row_boundary_not_writablereports a create whose boundary field is not writable, andbregctl testnames 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
classificationits registry configuration authored. It travels in thex-registry-attachmentextension, so it reaches/v1/registryand 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
attachmentdisposition inContent-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
Section titled “v0.28.0 beta-40”- BREAKING:
bregctl devandbregctl dev stoptake 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-expiredto erase expired assertion bytes and verification context while keeping receipts replayable. See retain, erase, and audit.
submitterTargetscan 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 onbregState,proposalVersion, andeffectDigest; ordinary field API names cannot reuse those names. Structured fields also accept an array schema root with declareditems. 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 publicschemaderives 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 unreleasedprofessional-licencesstarter must be initialized again because its correction fields changed without a migration path. See derive a registry from PublicSchema.evidencectl source addpreviews a connection from a stopped local registry and performs it with--apply, preserving records, revisions, and client identities. It requires a matching-versionbregctlonPATH. 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
Section titled “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_selectiontovalidate_service_selection_structurewith 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
--installedmode of the quickstart and demo launchers.
2026-08-20
Section titled “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-v1alpha1provider profile, the bounded relying-party search and ambiguity-safe selection, and thediscoveryctloperator 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--jsonreport 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
Section titled “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_jwtas 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
relayandrelayctlbinaries together on Linux amd64 and preserves the previous pair on failure. - Documented eager Evidence trusted-key validation, Mint’s reserved
scopeauthority 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
Section titled “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 underrelease/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
Section titled “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: truefixture 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
holderBoundBatchMaxSizea required member of theregistry.evidence-definitions/v1metadata 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_relayvocabulary prefix fromregistry-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
registryctlsource references from the current product surface while retaining their v0.19.0 retirement record.
2026-08-11
Section titled “2026-08-11”Documentation updates for the v0.19.0 beta-29 release, which replaced both Relay identities:
- BREAKING:
relayreplaces theregistry-relayruntime, andrelayctlreplacesregistryctl. The legacy runtime, the Rhai worker, theregistryctlbinary, 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
registryctlintrospection commands thatrelayctldoes 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.0image.relayctlhas 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
Section titled “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-oid4vcibinary to the Evidence installer and release inventory for all three supported platforms. - Added the v0.18.0 candidate documentation archive.
2026-08-07
Section titled “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
Section titled “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.0and made registryctl refuse an approved set issued before the retirement, including a version1.0document, a set carrying anotarylane, 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
Section titled “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.2archive 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.1archive 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.0archive while retainingv0.15.2as the latest published release until promotion completes.
2026-07-28
Section titled “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.1candidate 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.0archive while retainingv0.13.0as 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
Section titled “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
Section titled “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.0archived docset while retaining every earlier release archive. - Documented removal of Relay’s inert
provenance.consentresult member, the required pre-release consultation-state re-bootstrap, and Notary’s matching closed decoder. - Documented the shared deployment-waiver
referenceand optionalsummarycontract, with the retiredreasonfield rejected. - Updated Registryctl authoring examples to keep source adaptation, evidence
policy, and consumer decisions separate, and recorded the
registryctl.smoke.v1report schema. - Kept Solmara, hosted publication, external integration, OpenID, lifecycle, OpenSPP holdout, and pilot evidence as separate held gates.
2026-07-23
Section titled “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
Section titled “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.2archived 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-xml0.41 and the exactryu-js1.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.1archived 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
libc6findings 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
Section titled “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.0archived 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 initorregistryctl authoring editor.
2026-07-18
Section titled “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.0archived 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
Section titled “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.0archived 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
Section titled “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.0archived docset pinned to the beta-11 freeze source ref. - Updated registryctl install examples and current deployment tutorials to the
v0.9.0release 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_LOCKpath. 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
Section titled “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.4archived docset pinned to the beta-10 source ref. - Updated registryctl install examples and current deployment tutorials to the
v0.8.4release tag. - Recorded v0.8.3 as the first provenance-bearing root release.
2026-06-26
Section titled “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.3archived docset pinned to the beta-9 source ref. - Updated registryctl install examples to the
v0.8.3release tag. - The
v0.8.2docset remains archived; its release carries no tag-bound SLSA provenance.
2026-06-25
Section titled “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.2archived docset pinned to the beta-8 source ref. - Updated registryctl install examples to the
v0.8.2release tag. - Kept the
v0.8.1docset 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.1archived 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.1release tag.
2026-06-24
Section titled “2026-06-24”Documentation updates for the beta-5 source release:
- Added the
Beta 5docset 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 Notaryv0.7.0, and Registry Manifestv0.2.2. - Updated OpenCRVS, FHIR-adjacent, and standalone deployment tutorial references to the beta-5 release pins.
2026-06-22
Section titled “2026-06-22”Documentation updates for the beta-4 source release:
- Added the
Beta 4docset 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 Notaryv0.6.2, and Registry Manifestv0.2.2. - Updated source citations and tutorial install commands to beta-4 refs.
2026-06-21
Section titled “2026-06-21”Documentation updates for the beta-3 release candidate:
- Added the
Beta 3docset 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
mainURLs. - Added OpenCRVS and FHIR tutorial coverage for beta-3.
2026-06-20
Section titled “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
Section titled “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
Section titled “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 |