Changelog

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

• BREAKING: Proposal lifecycle event subjects use proposalReference and proposalRevision. Record event subjects keep recordReference and recordRevision. Update receivers that parse Proposal envelopes; mixed or open subject shapes are refused.

v0.44.0 beta-56

• Managed local installations expose one rstack command and install product components on demand. Registry Coordinator publishes its runtime and operator binaries, installer, and unified Node.js and Python client namespace for the first time. Its image remains held, as do Render client packages. Registry Document Store remains source-only. See Registry Coordinator and the client API.

• BREAKING: Base Registry Engine (BReg), Casework, and Scheduling start fresh pre-1.0 database baselines. BReg refuses the v0.43.0 attachment-verification shape; Casework and Scheduling install schema version 200 and refuse lower ledgers. Keep each old database for reconciliation, provision a fresh one, and apply the v0.44.0 package. Rebuild the BReg package with the v0.44.0 tooling and apply it with --initial. See upgrade and retire.

• BReg adds configured event-record descriptors, a caller-filtered read-only event-record view in its Rust, Node.js, and Python clients, presentation grouping, and configurable business identifiers. BREAKING: inspection formats advance, sending-side webhook names become hook names, eventDestinations becomes destinations.hooks, and attachment storage and verification use url instead of endpoint. See the BReg configuration reference.

• Scheduling adds composed bookings, named resource reservations, records-managed arrival windows, source busy import, operational appointment reads, source-managed assisted booking, attendance observations, and signed purpose-specific events. Casework adds approval templates and can count negative advice in a non-final stage without settling the review.

• Registry Evidence can generate fixed request bindings from selector fields and can set a target signing-validity maximum up to one year. BREAKING: the Evidence OID4VCI runtime requires a durable audit destination and a keyed-pseudonym hash key before startup. See configure Evidence OID4VCI.

• Evidence adds library-only building blocks for Token Status List checking and status-ledger transitions. The running service does not call them, and v0.44.0 does not issue credentials with a status claim. The OID4VCI adapter routes exchange state through a store interface, but released configuration still selects the in-memory store and cannot select the PostgreSQL backend.

• The source tree includes a synthetic G2P and P2G payment simulator for lab and workflow tests. It binds to loopback by default and requires explicit --allow-network to listen on a non-loopback address. The simulator never moves money and is not a released payment rail or runtime artifact.

• BREAKING: command reports use explicit --format human|json; Manifest separates artifact selection from report encoding; client response bounds, attempt and connection timeouts, and mutation retry counts use their full parameter names. Update scripts and client construction together.

v0.43.0 beta-55

• v0.43.0 continues the forward state path from v0.42.0. BREAKING: active Base Registry Engine (BReg) Records cannot reference tombstoned targets. Build a successor package against the deployed baseline, validate it on a representative restored-data copy, repair invalid active references through the current package, and repeat validation before activating the successor and switching runtimes. bregctl plan does not inspect live rows. See upgrade and retire.

• BREAKING: current product checks reject prohibited Unicode display controls and same-namespace identifier definitions differing only by - versus _. Run the applicable product checks before cutover and repair the reported definitions. Supported multilingual shaping and direction marks remain valid; equivalent peer labels warn unless --deny-warnings is selected. Discovery’s current parser checks title and description, while its immutable v1alpha1 schema, context, and SHACL remain unchanged. See configuration files.

• Base Registry Engine (BReg) inspection retains authored labels on fields, datasets, access profiles, and hooks. Model inspection links objects to per-document source paths so a tool can distinguish authored members from compiled defaults where those members correspond to source. Lifecycle inspection describes each state’s responsibility, including the conditions for submitted work. The model, access, and actions formats advance to v1alpha6, proposals to v1alpha2, and lifecycle to v1alpha7; select their matching schemas and rebuild packages. See authored values and display.

• Display-only BReg successor packages activate as metadata updates and retain compatible frozen Proposal submissions. Unchanged rebuilds remain empty plans. Casework routing findings point to the authored rule or stage and retain independent errors without duplicate findings for derived projections.

v0.42.0 beta-54

• BREAKING: v0.42.0 reads no state that v0.41.0 wrote. The Base Registry Engine (BReg) carries no state migration from v0.41.0 and names no refusal for an earlier database, so point it only at a fresh one. Casework, Scheduling, and Messaging each install their schema as one baseline numbered 100 and refuse a ledger below it at plan, apply, and startup. Evidence needs a newly authored normalized project, target, and target authority. Migration: finish, drain, or record open work, keep each v0.41.0 database unchanged for reconciliation and rollback, and apply the v0.42.0 packages to fresh databases as upgrade and retire describes. See upgrades and state.

• BReg requires PostgreSQL 17 or later and a UTF8 database. Generated text columns and indexes use the built-in pg_catalog.pg_c_utf8 collation, and a non-UTF8 database is refused with recovery guidance. Migration: provision the fresh BReg database on PostgreSQL 17 or later with UTF8 encoding.

• BREAKING: BReg projects declare recordTypes and Actions, and durable Proposals replace the entity-backed change-request model and its routes, with no compatibility layer. The Rust, Node.js, and Python clients use standalone Proposal methods (startProposal, prepareProposal, executeProposal, recoverProposal, the Proposal attachment methods, getProposal, and listProposals); immediateActions becomes actions, selectImmediateAction becomes selectAction, contractFingerprint becomes revision, and BReg metadata is version 2. The Proposal list takes limit and refuses top; ingestion runs take cursor, answer nextCursor, and refuse after. Proposal documents and events carry a required turn, lists filter by turn and state=rejected, and a page may hold fewer than limit items. A Proposal event’s subject.recordReference is /v1/proposals/{id}. A rejecting Review ends the Proposal in the terminal state rejected and commands answer 409 proposal.rejected; a changes-requested result records review-returned. Under required Review applicationStatus.state reads awaiting-review until approval, application-refused means only an executor refusal, and the apply link reports review-changes-requested or review-ended with recovery revise. applicationStatus.recovery is retry or correct-input, and link availability no longer lists terminal. bregctl explain lifecycle, bregctl explain events, and bregctl explain routes answer v1alpha6. Migration: rewrite the project, rebuild the package, update clients and receivers together, keep paging while nextCursor is present, and start a new Proposal after a rejection. See manage changes.

• BREAKING: an immediate BReg Action whose declared field guard fails at commit answers 412 action.guard_failed instead of 412 precondition.failed when the current-target admission checks pass and the selected profile can read the failed guard’s target fields. The code confirms that blocker; it does not promise the Action would otherwise succeed. A stale condition or a guard the caller cannot read remains 412 precondition.failed. Migration: clients that match precondition.failed, for example to offer reload and retry, must accept the new code.

• BREAKING: a decided Casework ReviewResult and every ReviewDecisionReceipt name the selected outcome, and BReg reads it. An approve without an outcome is refused with 400 request.invalid and reason outcome-not-declared, a policy with purpose: approval must declare its approval outcomes, and approvals in one stage must name the same outcome (approval-outcome-differs). Every outcome declares publicReason: required, optional, or none; a decision’s publicReason is bounded at 2000 bytes and released to the producer. A private reason over its bound answers maximum-bytes-exceeded instead of text-invalid. Migration: upgrade Casework and every review producer, including BReg, together, because mixed versions leave an approved Proposal submitted; add publicReason to every outcome and send outcome with every approval.

• BREAKING: Casework replaces source-owned WorkItems with one ReviewPolicy, ReviewRequest, ReviewTask, Decision, and ReviewResult model and refuses retained legacy schemas. The project format follows the cross-product configuration conventions: duration objects such as after: {hours: 48}, terminalRetentionDays and accountabilityRetentionDays, retention: {receiptRetentionDays} for trusted producers, ID-keyed mappings in place of lists, type: stage, anchor objects, atRisk: {before: {workingDays: N}}, and no completeOn or routing when: {activity}. Producer findings read no-policies, too-many-policies, invalid-policy, duplicate-policy, receipt-retention-out-of-range, and receipt-retention-exceeds-result-retention. Task list, next-task, and holdings reads finish a bounded scan or refuse review.query-too-broad. In Rust, ClockPolicyError gains Calendar { at, reason } and is no longer Copy. Migration: rewrite the project from the error each old spelling reports, use a fresh database, update scripts that match the old codes, and narrow broad queues. See change a Casework package.

• BREAKING: configuration names converge. BReg moves idempotency.receiptRetentionDays and eventDelivery.payloadRetentionDays into a top-level retention block as receiptRetentionDays and hookPayloadRetentionDays. BReg and Scheduling taskGrantStatus entries name statusResource instead of caseworkResource, and the Rust field TaskGrantStatusConfig::casework_resource becomes status_resource. Scheduling retention.attemptReceiptRetentionDays and Messaging retention.submissionReceiptRetentionDays become retention.receiptRetentionDays, at most 365. Messaging and Scheduling default scopeClaim to scope, and Scheduling defaults readsScope to scheduling:read and explainScope to scheduling:explain. Old keys report config.removed-key. Migration: rename each key, and set the scope settings explicitly when your issuer emits the earlier spellings.

• BREAKING: every token-verifying runtime, including Coordinator source builds, uses one issuer network policy. An operator-declared issuer or JWKS URI may resolve to a private or loopback address; a discovered cross-origin jwks_uri must use HTTPS and may not. Cloud metadata and link-local addresses are always refused, and plain HTTP beyond loopback needs allowInsecureHttp: true. Migration: declare a private key endpoint as jwksSource: {type: uri, uri: ...} or serve it from the issuer origin. See connect an OIDC issuer.

• BREAKING: BReg audit records name activation UUIDs activationId, and import authority records keep authorityActivationId. Activation refuses with apply.hooks.local-retained while local hook work needs the active package and audits the refusal with outcome refused. bregctl webhook list reports replayEligible only when operator permission and the proposal policy both allow a replay. Events without a compiled delivery, and every registry-platform-hooks envelope, are bounded at 1 MiB instead of 2 MiB. Scheduling reminder events use the shared hook envelope with content type application/json. A stalled stdout audit destination refuses audited requests with AuditUnavailableReason::Stalled after 5 seconds. Migration: update audit consumers and replay automation, run bregctl webhook drain before apply, project smaller events, and parse reminders as the hook envelope. See BReg webhooks.

• BREAKING: bregctl doctor names why a database connection was refused with startup.database.unreachable, capacity-exhausted, tls-refused, authentication-refused, missing, timeout, configuration-refused, or secret-refused instead of startup.database.connection-refused, and reports startup.database.catalog-drift instead of startup.database.unready. A canonicalBaseIri in the reserved .invalid namespace is refused as breg.registry.canonical-base-iri-reserved outside a database initialized for local. Migration: update automation that matches the old codes, and point canonicalBaseIri at a hostname you control. See inspect and diagnose.

• BREAKING: Evidence authoring uses one normalized evidence.yaml project with Sources, Functions, AssertionDefinitions, and Outputs, plus a separate target and complete target authority. EvidenceFixture control keys use camelCase, such as syntheticOnly and expectedValue, and old spellings report config.removed-key. Local development starts with evidencectl dev start PROJECT; dev --detach and dev --project are removed. Migration: author the current model, rename fixture control keys, run evidencectl test PROJECT --target TARGET --deny-warnings, and rebuild the package.

• BREAKING: the Discovery bindings and @registrystack/client no longer export validateSelection or validate_selection. registry-platform-calendar resolves a deadline in a daylight-saving gap to the first instant after it and in a fold to the earlier instant, and CalendarEvaluationError offset variants carry their values. Migration: call validateSelectionStructure or validate_selection_structure, and match the calendar error variants with { .. }.

• BReg serves one submitted Proposal version at GET /v1/proposals/{id}/submissions/{version}, shows a reviewer’s publicReason, sweeps expired Evidence uses and terminal webhook metadata, uses declared recordTypes[].indexes for filtered, sorted lists, and advertises a per-target availability check for immediate Actions with reference inputs. Casework accepts revokedKeyIds and maximumTokenLifetimeSeconds, keeps decided tasks in own-decision and supervision reads, and adds caseload preview and apply. Scheduling prunes outbox and observer metadata and expires raw claim owners after retention.claimOwnerRetentionDays. BReg, Casework, and Messaging local development pull PostgreSQL from Docker Hub again, so development egress allowlists need Docker Hub.

• Registry Coordinator source is in the repository, but v0.42.0 publishes no Coordinator binary, image, or client namespace. Build it from source as configure the Coordinator describes.

v0.41.0 beta-53

• BREAKING: the published registry-stack-client Python package requires Python 3.11 or later: its Requires-Python is >=3.11 (was >=3.10), its wheels are built against the Python 3.11 stable ABI and named cp311-abi3 (was cp310-abi3), and Python 3.10 is no longer supported. The floor moves because Python 3.10 reached end of life on 2026-10-01, so it no longer has the more than six months of upstream support that release preparation requires of a dependency pinned to a long-term-support line. Migration: run your application on Python 3.11 or later before you upgrade the client package, and name the cp311-abi3 file where an install command names a wheel from the GitHub Release. The client API reference gives the runtime and platform requirements of the package.

• BREAKING: the published @registrystack/client Node.js package and its platform packages @registrystack/client-darwin-arm64, @registrystack/client-linux-arm64-gnu, and @registrystack/client-linux-x64-gnu require Node.js 24.11.0 or later: their engines.node is >=24.11.0 (was >=22.12.0), and Node.js 22 is no longer supported. The floor moves because Node.js 22 reaches end of life on 2027-04-30, so from 2026-10-30 it no longer has the more than six months of upstream support that release preparation requires of a dependency pinned to a long-term-support line. Migration: run your application on Node.js 24 LTS, version 24.11.0 or later, before you upgrade the client package. The client API reference gives the runtime and platform requirements of the package.

• Standalone Linux binaries, including CLI tools, and the Base Registry Engine (BReg), Registry Casework, Registry Scheduling, and Evidence installers accept glibc 2.34 and newer, where they required 2.35. glibc 2.34 is the version the RHEL 9 family and Amazon Linux 2023 carry. See known limitations.

• Workflow actions/setup-go steps that compile AWS-LC-FIPS from source use Go 1.27.2, where they used 1.24.4. Go remains a build tool and is not shipped. The distinct canonical Linux builder still uses the snapshot-pinned Go package in its Debian 13 builder image.

• The four BReg, Registry Casework, Registry Scheduling, and Evidence installers start every staged Linux binary with --version before they select the release, as they already did on macOS. An installer checks the glibc floor of the release it was published with, so an installer asked for an earlier release could select binaries built for a newer glibc than the host carries; those binaries then failed at first run. The installer now refuses that release, names the binary that did not start, and leaves the installed toolset selected. See known limitations.

• BREAKING: BReg revision reads no longer accept the v0.38.0-and-earlier provenance that journaled an immediate action under its effect identifier. A detail read, or a list page containing such a revision, answers 503 source.unavailable. v0.41.0 reads only predecessor state created by a v0.40.0 apply, which already journals the entity’s canonical operation identifier and needs no change. An older deployment must first follow the v0.40.0 fresh-database migration, then upgrade that v0.40.0 predecessor state.

• BREAKING: BReg refuses a database without subject access-log storage before it binds a listener. Every apply from v0.38.0 onward installed that storage, including when the package declares no accessLog, so predecessor state created by a v0.40.0 apply needs no change. v0.41.0 does not upgrade older state in place: an older deployment must first follow the v0.40.0 fresh-database migration, then upgrade that v0.40.0 predecessor state.

• BReg’s Rust, Node.js, and Python clients accept additive object members in metadata and valid Problem envelopes. Unsupported must-understand capabilities disable only the affected binding, and unsupported descriptive metadata omits only the affected statistical dataset, descriptive change-request capability, selector, or spatial capability. An unknown temporal mode retains its inert temporal descriptor because null means the collection is non-temporal. Valid unknown Problem codes retain their HTTP status and trace ID without inferred semantics; malformed known fields and envelopes still fail as protocol errors.

• bregctl dev derives the local runtime’s principal and purpose claim mappings from the compiled project and refuses an unservable mixed mapping before it retains development state. caseworkctl source add uses the same-version bregctl explain access result to generate the casework-reader profile with the BReg project’s one compiled principalClaim, preserves exact test-bound client variants, and accepts equivalent trailing-slash spellings of the Casework review endpoint.

• The native citizen self-registration acceptance project combines ThunderID SMS signup, account-owned BReg applications, Casework review, and transactional Person creation, account linking, and program enrollment through configured BReg actions. It proves an adopter composition across existing product boundaries and adds no built-in business model or runtime.

• Registry Casework task templates can use authorizationMode: deferred with a lifetime of up to seven days. Immediate grants keep their 900-second ceiling. A deferred review grant is bound to the task’s assignment generation and ends when assignment or terminal state changes; deferred grants cannot carry Evidence bounds. Casework migration 0022 installs the grant-window constraints and assignment-generation trigger, validating the affected tables under an exclusive lock.

• The shared Registry Platform task-grant status transport now supplies BReg and Scheduling with TaskGrantStatusConfig, endpoint validation, status credentials, exact binding checks, and the default Casework status scope and route. BReg accepts optional statusScope and statusPath, and its development tooling can bind declared Casework task authorities into the generated runtime.

• BREAKING: BReg treats a 401 or 403 from the Casework task-grant status endpoint as an outage, answering 503 service.unavailable where it answered 412 precondition.failed. A 404 still refuses the grant with 412. The shared transport identifies itself as registry-task-status instead of registry-breg-task-status. Update alerts for a revoked or misconfigured status client, and update access-log user-agent matches.

• BREAKING: BReg validates each taskGrantStatus entry when it reads the runtime file and reports breg.runtime.invalid-task-grant-status at /taskGrantStatus, where activation reported breg.runtime.invalid-binding. The endpoint and client members now use their URL, external identifier, resource URI, and issuer types at that boundary. A configuration that v0.40.0 activated already meets the member rules. Update scripts that match the earlier diagnostic code.

• BREAKING: Registry Casework removes casework migrate and caseworkctl db. Use caseworkctl plan --runtime-config FILE followed by caseworkctl apply --runtime-config FILE. It also removes the casework.package.retired-manifest refusal. v0.40.0 already refused these commands and packages with the retired manifest, so no valid v0.40.0 package needs rebuilding for this cleanup. Rebuild an older retained package with caseworkctl package instead of matching the removed code.

• BREAKING: caseworkctl dev removes a database volume only when it carries the session ownership label. Every v0.40.0 session labels its volume. Before you remove an older unlabeled casework-dev-<identifier> volume, inspect and back up its contents. Removing the volume with docker volume rm permanently destroys its data. Follow the v0.41.0 release note.

• BREAKING: the Casework BReg source adapter refuses a legacy bare continuation cursor that names no request entity. Every cursor stored by v0.40.0 names its entity, so a v0.40.0 database needs no migration.

• BREAKING: caseworkctl dev reports five configuration refusals with exit status 1, where it reported caseworkctl.operational-failure and exit status 3: caseworkctl.dev.integrations-invalid, caseworkctl.dev.shared-client-mismatch, caseworkctl.dev.shared-task-authority-mismatch, caseworkctl.dev.source-binding-invalid, and caseworkctl.dev.borrowed-principal-invalid. A borrowed issuer session also refuses principalClaim: sub, because that claim names the issuer owner’s subject. Use a stable claim in every Casework access profile, register it for each client in both projects’ dev-clients.yaml, and update scripts that match the earlier status and code.

• BREAKING: CaseworkTaskAssertionSource classifies a Casework 4xx assertion refusal other than 408 or 429 as invalid-credential, where it classified every failure as unavailable. Request a new approval instead of retrying an expired, revoked, or absent grant.

• BREAKING: evidencectl build is now an unknown command. Use evidencectl package with the project directory as its positional argument and retain the same --target and --output options. evidencectl init and evidencectl new no longer accept the inactive --generate-keys option; remove it because a local project already creates disposable keys.

• BREAKING: Registry Scheduling requires a top-level taskGrantStatus in every runtime file. List one to 32 task authorities whenever the deployment requires current status or revocation checks, and for deferred work. taskGrantStatus: unchecked-final-fifteen-minutes checks only the grant’s remaining lifetime because the signed token does not identify its original mode. It admits any grant with at most 900 seconds remaining without checking revocation, including the final 900 seconds of a deferred grant. Use it only when the deployment accepts that stale-authority window. An omitted member is refused at startup with scheduling.runtime.missing-task-grant-status.

• BREAKING: Registry Scheduling removes three refusals for pre-v0.40.0 inputs. scheduling migrate is an unknown command; activate with schedulingctl plan and schedulingctl apply. scheduling.package.retired-manifest is replaced by the ordinary package-content refusals, so rebuild with schedulingctl package. schedulingctl.activation.earlier-release is replaced by schedulingctl.store-unavailable, so start from a new database when the retained policy uses the pre-v0.40.0 identity. A database activated by v0.40.0 needs no reset. Direct Rust consumers must remove RuntimeError::RemovedCommand, RuntimeError::exit_code, runtime::removed_command_refusal, RuntimeConfigError::RetiredPackageManifest, config::RETIRED_PACKAGE_MANIFEST_FILE, and StoreError::EarlierRelease.

• Registry Scheduling’s POST /v1/appointments/receipt and Registry Messaging’s POST /v1/messages/receipt use the original Idempotency-Key, request body, and verified caller identity to resolve the retained original success receipt. They do not return the request body or repeat the mutation. Both routes use current ordinary read authority. Scheduling can recover the receipt after the task grant ends. An unresolved receipt answers 409 receipt.unresolved, which does not prove that no effect occurred. The Rust, Node.js, and Python clients carry both routes.

• BREAKING (Rust API): registry_scheduling_core::ProblemCode and registry_messaging_core::ProblemCode gain ReceiptUnresolved. Add that arm, or a wildcard arm, to exhaustive matches.

• BReg and Casework local development pull the same pinned PostgreSQL image from public.ecr.aws/docker/library/postgres. Messaging pulls that PostgreSQL mirror and Mailpit from ghcr.io/axllent/mailpit. Development egress allowlists must admit public.ecr.aws and, for Messaging, ghcr.io. Retained BReg and Casework containers using the earlier Docker Hub PostgreSQL reference at the same digest remain accepted; BReg PostGIS sessions still use Docker Hub’s postgis/postgis image.

v0.40.0 beta-52

• BREAKING: v0.40.0 does not upgrade v0.39.0 configuration, packages, or databases in place, and it provides no automatic migration. Rewrite the configuration you keep, rebuild every package with the v0.40.0 tools, repin expected digests, and apply Base Registry Engine (BReg), Registry Casework, Registry Scheduling, and Registry Messaging to new databases. A new database holds no spent idempotency key, so a committed write replayed against it can execute again: finish recovering outstanding writes against the v0.39.0 runtime, and stop that runtime, before you direct callers to the new deployment. The forward state path starts at v0.40.0, and later releases again read the state their immediate predecessor wrote. Follow the upgrade steps; upgrades and state gives the rule.

• BREAKING: every maintained product reads its files under one configuration convention. Authored, operator, fixture, development-state, and report formats open with a product-owned apiVersion and kind envelope and follow shared reader rules, and a retired form has no compatibility alias. Registry Manifest’s exchange envelopes and the frozen Evidence Gateway deployment grammars keep their documented exceptions. The v0.40.0 release notes link the complete migration notes: 269 breaking items across nine product fragments, each with its replacement form, migration step, and diagnostic mapping. Read the fragment for every product you run. Configuration files states the shared rules and lists the formats by product.

• BREAKING: a variant block is tagged by type where its format documents one, including an issuer’s jwksSource and action and hook handlers. Multi-word protocol values, tooling statuses, and client error classifications are written in kebab-case where the product notes say so: for example, the Evidence problem code evidence.invalid_request is evidence.invalid-request, and the status label of evidence_http_requests_total is client-error or server-error. Update configuration and every comparison in scripts, clients, audit queries, and alerts from the old-to-new tables in the migration notes. Standard-owned words, including registered OAuth error codes, keep their standard spelling.

• BREAKING: offline checks report positioned, value-free diagnostics and share one exit contract: 0 when the input is accepted, 1 on a refusal or on a warning under --deny-warnings, 2 on a usage error, and 3 when an input cannot be read. bregctl check and schedulingctl check take --deny-warnings, where they took --deny-findings, and plain evidence check is offline: run evidence check --require-runtime-dependencies on the target host for the full proof. Update automation that matched earlier sentences, dotted field paths, diagnostic codes, report members, or product-specific exit values. See read a diagnostic and check a file before you deploy it.

• BREAKING: closed inputs refuse unknown or duplicate keys, explicit nulls, substitution outside a declared scalar position, invalid or duplicate identifiers, and out-of-range values. Delete an optional member written as null, and replace secret paths with the documented secret references. Shared URL fields refuse raw backslashes, whitespace, control characters, and a host the URL parser rewrites: write an internationalized host in punycode and an IPv4 address in canonical form.

• BREAKING: OIDC allowedClients is required, and a repeated client is refused. List the clients the deployment admits. Write unrestricted only where the product allows it: BReg accepts it, and Registry Scheduling and Registry Messaging accept it in no mode. A client listed under assertionIssuers names at least one issuer; remove an empty entry to grant it no exchange authority.

• BREAKING: a BReg registry serves authenticated callers only. anonymous on an access profile is refused as config.removed-key, and every route except the probes and the review completion receiver answers a request without a verified bearer token with 401 authentication.refused before any profile, query, or record is read. The breg_anonymous_refusals_total metric is removed, and a baseline package that granted unauthenticated access is refused.

• BREAKING: a BReg access profile groups its permissions as a mapping of entities, actions, and datasets, where it was one list, and requiredScopes is required on every profile as unrestricted or a list of at least one scope. Access to a statistical dataset is granted there as {dataset, operations} with the operations read-live, publish, and read-releases, and live and releases on a statisticalDatasets entry are refused. A standing agent profile, actorKind: agent without taskGrant, cannot hold publish: move it to a profile a person or service uses directly, re-lock affected modules, and rebuild the package.

• BREAKING: BReg spends an idempotency key once per configured issuer and verified caller across ordinary write routes. A changed write under a spent key answers 409 idempotency.conflict, and an exact retry after the receipt horizon answers 410 idempotency.expired and never executes again in that database. Use a new key for every distinct write. idempotency.receiptRetentionDays sets the horizon, 7 days by default and at most 365. BReg schedules no automatic sweep: run bregctl idempotency-retention erase-expired as drop expired idempotency responses describes.

• BREAKING: a BReg ingestion run belongs to the verified caller, where it belonged to an audit-keyed pseudonym, and no run, chunk, or receipt crosses the state reset. A bregctl data import checkpoint written against v0.39.0 cannot resume against the new registry: import again with a new checkpoint path.

• BREAKING: BReg governed record, history, statistics, attachment, GIS, ingestion-run, and discovery reads refuse HEAD with the concealed 404 an unsupported method receives. Send GET. /health, /healthz, and /ready still answer HEAD.

• BREAKING: every BReg governed action handler declares abi: registry.action-handler/v1, and a retained registry.action-handler/v2 declaration is refused with breg.action.handler-abi-invalid. An action’s evidence declaration alone selects Evidence access for its Rhai handler. Replace the v2 value, keep the evidence declaration, re-lock affected modules, and rebuild the package. Evidence consumption by an action remains a trial.

• Registry Casework adds reviewer and Supervisor discovery. Active review-task lists accept ownership=assigned-to-me and ownership=unclaimed, a decided single-task read includes decidedByCaller, and the decision author can recover a minimal decisionReceipt that excludes the private reason and the producer result. GET /v1/review-tasks/own-decisions lists the caller’s retained decisions, and GET /v1/review-tasks/supervision lists active and retained terminal tasks in a Supervisor’s current queues without a holder, submitted context, private reason, or producer result. An expired, erased, mismatched, or unauthorized continuation answers 410 review.result-expired: restart without a cursor. See the Registry Casework API.

• BREAKING: Registry Casework activation refuses a policy package that no longer declares the review producer of an in-flight review. caseworkctl plan and caseworkctl apply report casework.activation.stranded-work, naming the producer and the number of in-flight reviews, and the runtime repeats the refusal before it listens. Let the reviews that producer submitted reach a result before you remove or rename it, or set package.acknowledgeStrandedWork to the digest the refusal names.

• BREAKING: Registry Messaging scopes a spent submission key to the caller’s verified issuer and subject, and rotating the audit hash key no longer frees it. A changed request under a key whose receipt has passed retention.submissionReceiptRetentionDays answers 409 idempotency.key-reused for as long as the message record is held. Once retention.recordRetentionDays has cleared the record and its request hash, every request under the key answers 410 idempotency.expired. Deploy Registry Messaging gives the drain to finish before you move senders to the new runtime.

• Registry Scheduling owns a hold or an appointment by the verified issuer and subject that booked it, so rotating the audit hash key no longer detaches a caller from its claims.

• BREAKING: several commands rename an argument and accept no alias. evidence-oid4vci check, inspect, and serve take --runtime-config FILE and EVIDENCE_OID4VCI_RUNTIME_CONFIG, where they took --config FILE and EVIDENCE_OID4VCI_CONFIG. schedulingctl records apply and intents take the runtime file as --runtime-config FILE, where it was positional. caseworkctl simulate takes --simulation FILE, where it took --fixture FILE. evidencectl refuses --project on target explain, dev stop, dev clean, source add, source suggest, source detach, fixtures run, and tooling editor: pass the project directory as the positional argument.

• evidencectl dev start PROJECT --target TARGET --issuer-project OWNER --preserve-target-authenticated-context keeps a selected local target’s reviewed human authenticated-context bindings for a borrowed BReg issuer. A retained local session keeps the mode it started in: stop and clean it before you start it in the other mode.

• The BReg, Registry Casework, Registry Scheduling, and Registry Messaging clients report an unknown mutation outcome and resend a keyed mutation under the same key, with the same request, at most twice by default. A 4xx response or an unusable Retry-After stops the resend. See unknown outcomes and the same-key retry.

• The unified Node.js and Python clients add Registry Scheduling: the scheduling namespace of @registrystack/client and the registry_client.scheduling module of registry-stack-client. BReg immediate-action preparation and recovery are available in Node.js and Python. The Rust, Node.js, and Python BReg clients read the caller-filtered statisticalDatasets descriptors the runtime publishes, and BReg and its clients accept a record or GeoJSON continuation of up to 10,978 bytes. See the client API reference.

• API stability and versioning publishes the compatibility promise that takes effect at 1.0: the promised products and surfaces, the experimental surfaces, and the deprecation rules. v0.40.0 remains pre-1.0, and this release does not activate the promise.

• BREAKING: for direct Rust consumers of the workspace crates, RuntimeConfigError exposes diagnostics in place of RuntimeConfigErrorKind, kind(), code(), field(), and message(). registry-platform-dispatch and registry-platform-hooks write their state words in kebab-case, Registry Manifest removes render_entity_shacl in favor of render_shacl, and the shared APIs that only the retired Registry Relay consumed are removed. The Platform changelog keeps the complete inventory of removed items.

v0.39.0 beta-51

• BREAKING: Registry Relay is retired and absent from 0.39.0. The relay and relayctl binaries, the Relay installer, the Relay container image, the registry-relay-client Rust crate, and the relay namespace of the unified Rust, Node.js, and Python clients are removed, and Registry Discovery refuses a package index that contains a Relay service. v0.38.0 is the last release that ships them, and Relay receives no security fixes once 0.39.0 is released. There is no automatic migration: choose Base Registry Engine, Evidence Gateway, or Registry Manifest for each consumer and source, remove relay client imports, and remove Relay origins from a Discovery index and rebuild it with discoveryctl package before upgrading. The Registry Relay retirement decision gives the scope, the support boundary, and where the v0.38.0 release and documentation remain available.

• BREAKING: before 1.0, a release reads only the state its immediate predecessor wrote. v0.39.0 reads state written by v0.38.0 and nothing older, and the paths that served only earlier releases are removed from Base Registry Engine (BReg), Registry Casework, Evidence, and Registry Scheduling. Upgrade one release at a time and finish each release’s upgrade steps before starting the next. Each product changelog lists every removed command, option, key, and refusal code.

• BREAKING: every BReg project compiles to a new registryRevision and a new managed schema fingerprint, because every package installs the statistical release store, and a package v0.38.0 built no longer loads in the v0.39.0 runtime. A project that declares immediate actions, derived string, text, decimal, integer, or vocabulary fields, or one vocabulary on projected fields that admit different codes also changes its generated row policy, views, or codelist. Rebuild it with the v0.39.0 bregctl test and bregctl package, each naming the deployed package with --baseline-package, as test and package the successor gives in full, and apply it with bregctl plan and bregctl apply before switching the runtime. Then repin any Registry Casework BReg source for it with caseworkctl source add ... --apply and package, plan, and apply the Casework project once. A package whose project declares a change-request planner is now accepted as the predecessor, where earlier releases refused it and no successor of it could be built or applied.

• BReg adds governed statistical datasets. A root project declares count datasets under statisticalDatasets; a live profile reads exact counts its own list grant could already count, one publisher publishes immutable versioned releases under minimum-count suppression and rounding, and a released-data reader needs no record permission. Seven operations under /v1/statistics/ serve JSON or CSV, bregctl statistics publish and withdraw drive the lifecycle over HTTP, and the Rust, Node.js, and Python clients carry the operations. Publish a statistical series gives the steps, and the publish statistics states the inference risks the disclosure method accepts.

• BREAKING: BReg derived SQL accepts only reviewed PostgreSQL grammar. JSON_QUERY, JSON_TABLE, XMLTABLE, SQL/JSON aggregates and constructors, XML functions, NATURAL and USING joins, column alias lists, whole-row references, and casts outside the reviewed built-in scalar types are refused; JSON_VALUE and JSON_EXISTS stay available. A derived value that does not fit its declared length, scale, precision, range, or vocabulary is no longer truncated or rounded: the generated view raises a value-free error and an API read of it answers 503 source.unavailable.

• BREAKING: the BReg contains and prefix text-search operators (contains and startswith in $filter) match without regard to case on string, text, and vocabulary-code fields. %, _, and backslash match literally, and equals and in keep exact, case-sensitive matching.

• BREAKING: a BReg background worker or the metrics listener that panics or returns before shutdown ends breg with exit status 1, where the process kept serving without the task. Run breg under a supervisor that restarts it on failure. The metrics listener publishes breg_worker_last_success_age_seconds, breg_queue_oldest_pending_age_seconds, and breg_active_package_info with the package digest the process verified at startup.

• BREAKING: bregctl apply and plan report a migration lock another session holds as apply.database.in_progress, where they reported apply.database.unavailable, and the maintenance commands report it under their own in_progress codes. The webhook, request-retention, import-authority, and evidence-retention commands refuse a package that package.expectedDigest does not pin under *.package.refused codes. bregctl apply and plan take --expected-digest and refuse another package as apply.package.digest_mismatch before any database contact.

• BREAKING: a BReg reviewed migration’s rehearsal.json no longer carries proofs, and bregctl test and package refuse a receipt that still does with migration.review.receipt_proofs_retired. bregctl test --fingerprint-only measures the schema fingerprint a fresh install of the candidate produces without running fixtures.

• BREAKING: the BReg WebAssembly executor builds Wasmtime without its default features and refuses a handler module that uses GC types, exception handling, or externref. A build without the wasm feature refuses a WASM hook handler with hook.handler.wasm_build_unsupported. The executor runs Wasmtime 48.0.5, which carries the fixes for RUSTSEC-2026-0325, RUSTSEC-2026-0326, and RUSTSEC-2026-0327.

• BREAKING: bregctl dev takes PostgreSQL loopback port 15432 on a first start, where it took 55432, and caseworkctl dev takes 15433, where it took 55433. A session that already started keeps its port. bregctl dev pins a session on its compiled content, so run bregctl dev stop --remove on a session an earlier release started.

• bregctl check reports access.profile.create_required_field_not_writable when a direct create or import grant omits a required writable stored field. A missing or malformed Idempotency-Key on a BReg immediate action names the header in fieldPath, and the Rust, Node.js, and Python BReg clients expose the validated fieldPath of an accepted problem.

• A Registry Casework inbox view that is empty over a recently reconciled source returns complete. Retry a budget_exhausted page that waited only for source discovery without a cursor, and deduplicate the retried walk by itemId. caseworkctl source add --casework-endpoint URL sets the Casework endpoint of the local BReg review authority, and caseworkctl dev reports a local session failure under caseworkctl.dev.* codes.

• BREAKING: Registry Discovery service search accepts serviceKind=evidence only and no longer takes the semanticClass and operationFamily filters. A search that sends serviceKind=relay or either filter answers 400 with the invalid-request problem.

• A nightly channel publishes evaluation builds from protected main as immutable GitHub prereleases and container image tags, with no npm package, PyPI package, or documentation site. The BReg, Casework, and Evidence installers downloaded from a numbered release stay pinned to that release. Use a numbered release for a production deployment.

v0.38.0 beta-50

• BREAKING: a Base Registry Engine (BReg) direct create, patch, or batch item whose resulting row falls outside the caller’s row boundary answers 412 precondition.failed before any write, where it answered 503 service.unavailable. Retrying the unchanged request cannot succeed, a batch carrying one such item commits none of them, and a genuine PostgreSQL privilege failure still answers 503. Handle a 412 on a create as a boundary refusal, not a retryable outage.

• BREAKING: the generated BReg OpenAPI document lists 412 precondition.failed on every create and batch operation reachable through a profile with rowBoundaries, so such a project compiles to a new registryRevision and a package an earlier release built for it no longer loads. Rebuild it unchanged with the v0.38.0 bregctl test and bregctl package, each naming the deployed package with --baseline-package, as test and package the successor gives in full, and apply it with bregctl plan and bregctl apply, then repin any Registry Casework BReg source for it with caseworkctl source add ... --apply and package, plan, and apply the Casework project once.

• A BReg entity may declare accessLog to keep a subject-facing log of reads of its records. The record subject reads it at GET /v1/records/{route}/{id}/access-log, retention defaults to 90 days, trustedIntermediaries may forward the original requester and purpose, and exemptions delay a documented entry without omitting it. The log is stored apart from the operational audit, and a failed log insert refuses the read.

• BReg automatic review executors can renew credentials with privateKeyJwt, and bregctl review-recovery retry-application requeues an executor-denied job. Webhook dead letters keep a closed failure reason, and bregctl webhook discard closes eligible work captured under a superseded binding without replaying it.

• BREAKING: Registry Casework and Registry Scheduling activation (plan, apply, and status) and runtime startup refuse a PostgreSQL server older than 17, before any migration or activation write. Upgrade the database server before upgrading either product.

• BREAKING: Registry Scheduling publishes the v1alpha2 HTTP contract. Holds and appointments carry a required externalReferences array of opaque {product, recordType, identifier} links, a hold or direct booking may send it, and a reschedule must omit it. GET /v1/appointments lists the caller’s own appointments carrying one exact reference. The fresh-install baseline stores the references, so configure and apply a fresh database before restarting, and upgrade the runtime before any client sends the field.

• BREAKING: an Evidence requirement’s subjectRoles[].role is limited to 64 bytes instead of 128, in the bundle schema and at startup. Shorten a longer role and every input that names it before upgrading.

• An Evidence http-json source may declare evidence to read one predefined assertion from another Evidence deployment, verified against pinned trustedJwks before projection. Separately, a source that does not declare evidence may set forwardAccessAttribution to send the verified requester and purpose to a source that trusts this service as an intermediary; startup refuses a source that sets both. evidence-oid4vci validates its whole catalog and every offer before an offer secret exists.

• The release publishes a discoveryctl Linux amd64 binary and a standalone Registry Scheduling Linux amd64 runtime binary beside the Scheduling image and schedulingctl binaries.

• Registry Messaging and Registry Render ship for the first time, each as release binaries and a ghcr.io/registrystack/<name> image, and the Evidence OID4VCI adapter gains the ghcr.io/registrystack/evidence-oid4vci image. The unified Node.js and Python clients add a messaging namespace. See deploy Registry Messaging and run Registry Render in serve mode.

• breg-mcp ships for the first time, a supporting service beside BReg: an MCP gateway a chat host uses to act for one verified citizen. It reads the citizen’s own record and creates or patches change-request drafts for it, and has no code path to submit, revise, cancel, or apply one. It verifies the chat host’s token as an OAuth protected resource and, for every tool call, exchanges it (RFC 8693) for a registry token with the gateway as actor, so the chat host’s token never reaches BReg. It takes a draft’s target from the citizen’s own linked record, never from a tool argument. breg-mcp check validates the runtime configuration and breg-mcp serve runs the gateway. This release publishes breg-mcp and breg-review as binaries for Linux amd64, Linux arm64, and macOS arm64, and as the ghcr.io/registrystack/breg-mcp and ghcr.io/registrystack/breg-review images; the BReg installer does not install them. See citizen chat assistant.

• breg-review ships for the first time, a server-rendered review page beside the gateway. The citizen signs in with an authorization code and PKCE, reads the draft BReg holds under their own token, and submits it; the page holds no authority of its own. breg-review check validates the runtime configuration and resolves its secrets without opening a socket, and breg-review serve listens at its explicit private listener.bind and stops cleanly on SIGINT or SIGTERM. Its shared audit stream records the action, the changeRequestId, keyed principalPseudonym and clientPseudonym values, and the outcome, never a field value or token.

• The VS Code and Zed integrations cover every maintained product, and the language server reads only .yaml, .yml, and .json product documents.

v0.37.0 beta-49

• BREAKING: Base Registry Engine (BReg) refuses to compile a standing agent profile, one with actorKind: agent and no taskGrant, that holds submit_request, revise_request, cancel_request, or apply_request, with access_profile.standing_agent.operation_forbidden, or that holds create or patch on an entity without a changeRequest, or import, tombstone, or batch on any entity, with access_profile.standing_agent.direct_mutation_forbidden. A standing agent carries no human approval, so it may read and author change-request drafts while a human submits them; move the lifecycle operations to a profile the person uses directly.

• BREAKING: BReg refuses to compile a standing agent profile that holds an immediate-action permission, with access_profile.standing_agent.action_forbidden. An immediate action commits its effects at once, with no draft for the person to confirm, so a token carrying a trusted act no longer reaches any immediate action. Move the action permission to a profile the person uses directly.

• BREAKING: BReg refuses to compile a module that contributes an access profile declaring a taskGrant, whether on an entity it adds or on one it extends, with access_profile.task_grant.module_forbidden. Task-grant ceilings are checked only where grants are authored, in project accessProfiles; declare the task-grant profile there.

• BREAKING: BReg accepts an act claim of exactly {sub, iss} when iss equals the verified token issuer, as a token exchange writes it, beside exactly {sub}. A token whose act.sub is the trusted actor for its client is an agent token whatever its registry_actor_kind claim says, so it no longer satisfies a profile that declares actorKind: human.

• BREAKING: BReg admits a token carrying a trusted act only on an access profile that declares actorKind: agent. A profile that declares no actorKind refuses such a token, so a delegated caller cannot borrow the operations of a profile written for people using BReg directly. Tokens without act are admitted as before.

• BReg’s audit journal records the agent behind a delegated request. A request carrying a trusted act writes the shared authorization object on its refusal, mutation, and request lifecycle records, with actor kind agent and a keyed actorPseudonym scoped to the package revision beside the principal and client pseudonyms. The raw actor identifier is never stored, and task-grant records without act are unchanged.

• BReg’s audit journal records delegated authority on reads. A read’s terminal record, for records, lists, lookups, revisions, history, and snapshots, now carries the authorization object for a task-grant or delegated token. Direct tokens record no such object, as before.

• registry-platform-ratelimit is a new shared crate with two in-memory keyed limiters, TokenBucketLimiter and FixedWindowCounter, each capped at a fixed number of tracked keys. Evidence now uses it for its request budget and failed-selector counter with no change in behavior: the same refill, key cap, pruning, and refusals.

• Platform crates gain token exchange, sign-in, and security header primitives. ExchangeAuthorization::upstream sends an optional actor token with an RFC 8693 exchange. PrivateKeyJwt::redeem_authorization_code redeems an authorization code with PKCE and the configured resource, and returns any ID token unverified. CspBuilder::deny_by_default starts a policy from default-src 'none', and with_form_action and with_style_src add directives to it. AuthorizationAuditEvent::without_purpose builds an allowed or denied event for a product that records no purpose. The test-authorization-server feature of registry-platform-testing adds a local authorization server for authorization code, client credentials, and token exchange tests.

• BREAKING: a Base Registry Engine (BReg) record or query 400 names the member or parameter at fault in fieldPath, where it carried none before; detail and code are unchanged. A create body names /data or /data/<apiName>, a JSON Patch document names /<n> and its members, a batch body names /items, /changeContext, and each item’s members, a malformed Idempotency-Key and a batch If-Match name the header, and a query.invalid refusal names the parameter. An unknown and a withheld name answer the same problem and are never echoed. The v0.37.0 Rust, Node.js, and Python BReg clients accept fieldPath on request.invalid and query.invalid; upgrade a client that rejects unfamiliar problem members with the runtime. See Mutations.

• BREAKING: a BReg JSON Patch test of a field the grant does not let the caller read answers 400 request.invalid at /<n>/path before the record is read, like a test of an unknown field, instead of a 404 or 412 first. Test only fields the grant lists in readableFields. A read path whose target entity has no permission entry in the caller’s profile answers with the records the path grant authorizes instead of 503 source.unavailable.

• BREAKING: Registry Casework selects the source profile only by the Registry-Source-Profile header on decide and both attempt recovery routes. DecideRequest no longer carries sourceProfileId, RecoverAttemptRequest is a closed empty object, and a body that still sends sourceProfileId is refused with 422 request.unprocessable; the Rust, Node.js, and Python clients follow. caseworkctl dev token writes the Registry-Casework-Profile line into a profile client’s header file, and a review inbox left empty only because that header is missing answers 400 source-profile.required. See Revisions, actions, and recovery.

• BREAKING: every Casework mutating route parses its JSON body strictly: a duplicate object member at any depth, or a raw integer IEEE 754 binary64 cannot represent exactly, is refused with 422 request.unprocessable, and a Content-Type that does not parse whole as application/json or application/*+json is refused with 415 request.unsupported-media-type. Send such an integer as a string.

• Registry Casework refuses a zero or over-maximum page limit with the new closed problem code request.limit-out-of-range, and ReviewTaskPage carries a required status. A plain item, history, or clocks read across a moved source binding returns the retained item without actions instead of 409 work-item.proposal-changed. A source binding or policy field an adapter refuses is named by its key path. See Problem codes.

• Registry Scheduling starts a hold’s time to live once its capacity transaction takes its locks, so a hold created under contention keeps its whole holdPolicy.ttlMinutes, and answers availability for a horizon or start past the last representable instant instead of panicking the request.

v0.36.0 beta-48

• BREAKING: Base Registry Engine (BReg) records every activation in a database ledger and ships unsigned, environment-neutral packages named by their package digest. Package signing is removed, so upgrade to v0.35.0 first: this release does not read a predecessor package without a SHA256SUMS envelope. bregctl plan and bregctl status report what an apply would change and what the database activated, and bregctl apply without --initial adopts a database an earlier release installed. package.environment and package.instanceId move to the runtime file’s identity, package.sequence is removed, and the runtime package block keeps only root and expectedDigest. Every package’s schema fingerprint changes, and a project that declared a package identity compiles to a new registryRevision, so rebuild each package with the v0.36.0 bregctl package. In split-role mode, plan, apply, and startup refuse a runtime role that can write the ledger or the registry state. After upgrading BReg, re-import each BReg source into Evidence once and repin each BReg source in Casework. See Upgrade in this order.

• The shared audit writer recovers an active file whose final line a crash tore: the next start moves those bytes to the owner-only side file <audit.path>.torn, truncates to the last complete line, and logs it, instead of refusing to start. A configured audit.path ending in a companion suffix is refused. Evidence Gateway and Scheduling write operational logs to standard error, so a stdout audit destination carries audit entries alone, and evidencectl audit show reads histories with request-batch entries and names denials, transient failures, and earlier operations left without an outcome. See Audit retention and Operate the Evidence Gateway audit log.

• BREAKING: evidencectl follows the shared ctl report and exit contract. Under --format json each command writes one object on standard output opening with ok, command, and status, all member names camelCase, and nothing on standard error; command replaces the former operation member, and fixture reports use evaluatedCases, failingCase, expectedClass, and observedClass. An unreadable file or a missing local dev session exits 3 instead of 1. Commands that read one project take it as a positional <project>; the former --project flag stays accepted but hidden on them. source import, source diff, source update, and target new keep their documented --project, the access commands and audit show still act on the current directory, and doctor keeps its --project option. test and fixtures run accept --format junit, and dev start --name-prefix sets the local issuer container name prefix. Update scripts that read operation or snake_case fixture keys. See evidencectl.

• BREAKING: Registry Casework activates a package in the database with caseworkctl plan and caseworkctl apply, recorded in an activation ledger, and casework serve only reads that activation. casework migrate and caseworkctl db migrate are removed and exit 2 naming the two commands. runtime.yaml requires identity.databaseId. In split-role mode, apply, plan, and startup refuse a runtime role that owns a Casework object, can create in the schema, or holds TRIGGER, and any trigger no Casework migration creates, naming the statement to run. Startup refuses a Base Registry Engine (BReg) source whose pinned sourceRevision differs from the registry revision it serves, and caseworkctl check PROJECT --against-breg-package DIR compares a pin with a closed BReg package before deployment. plan refuses a runtime role that cannot read the ledger, naming caseworkctl apply. A caseworkctl dev session created by this release connects with one database role. To upgrade, add identity.databaseId, repin each BReg source after upgrading BReg, then plan and apply once before starting the runtime; with split roles, a trigger an operator added to a Casework table blocks startup until it is dropped. See plan, apply, and serve.

• BREAKING: Registry Scheduling activates a package with schedulingctl plan and schedulingctl apply, recorded in an activation ledger, and scheduling serve writes no activation state. scheduling migrate is removed and exits 2 naming the two commands. runtime.yaml requires identity.databaseId. In split-role mode, plan, apply, and startup refuse a runtime role that owns a Scheduling object, can create in the schema, or holds TRIGGER, and any trigger attached to a scheduling_* table, naming the statement to run; apply never revokes TRIGGER itself. plan refuses a runtime role that cannot read the ledger, naming schedulingctl apply. To upgrade, add identity.databaseId and run schedulingctl apply once before starting the runtime; with split roles, a trigger an operator added to a Scheduling table blocks startup until it is dropped. See products/scheduling/CHANGELOG.md.

• BREAKING: every caseworkctl and schedulingctl --format json report opens with ok, command, and status, in that order, as evidencectl reports do. ok is true exactly when the exit code is 0, and a failure without a report of its own names its exit class as domain-refusal, usage-error, or operational-failure with at least one diagnostic. caseworkctl reports move to caseworkctl/v1alpha3, and the schedulingctl records report’s command is records apply. See products/casework/CHANGELOG.md and products/scheduling/CHANGELOG.md.

• schedulingctl is published as a release binary for linux-amd64, linux-arm64, and macos-arm64, like caseworkctl. The BReg, Casework, and Scheduling images each carry their operator tool beside the runtime, at /usr/local/bin/bregctl, /usr/local/bin/caseworkctl, and /usr/local/bin/schedulingctl, built from the same source. The entrypoint stays the runtime, so a serving container is unchanged; run plan, apply, and status from the image you serve by overriding the entrypoint, or from a Kubernetes Job command:. The Scheduling runtime stays an image-only artifact and has no installer. See Activate from the image and Run plan, apply, and status from the image.

v0.35.0 beta-47

• BREAKING: Base Registry Engine (BReg) gives every reference field a btree index unless a declared index or a unique constraint without when already leads with it, and bregctl check reports entity.list.unindexed_filter and entity.list.unindexed_sort for a filterable or sortable list field no index leads with. The findings fail a check only under --deny-findings, so a pipeline that runs bregctl check --deny-findings fails until those fields are indexed. An upgraded engine refuses an active package whose project has a reference field no index leads with, because its compiler now derives a different schema: doctor reports startup.package.refused with the package compiler derivation failed. Build and apply a successor with the upgraded bregctl before starting the upgraded breg; the plan classes each new index as compatible additive, and its plain CREATE INDEX blocks writes to that table until the migration commits. See indexes and monitor and recover.

• BReg sessions name themselves in pg_stat_activity: breg for the runtime and bregctl for operator commands, unless the connection URL sets application_name. Runtime sessions carry idle_in_transaction_session_timeout of 120 seconds as a startup option, so PostgreSQL ends a session left idle inside an open transaction and the pool replaces it. Poolers must run in session mode; one that drops the startup options needs the bound set on the runtime role. See set a PostgreSQL baseline.

• BReg runtime sessions carry jit=off as a startup option placed before any options in the connection URL. Row-level security made the planner’s cost estimate for a short filtered collection page cross the JIT thresholds, and compiling that plan took several times longer than running it. An operator who wants JIT back adds -c jit=on to the URL options. Poolers must run in session mode; one that drops the startup options needs jit = off set on the runtime role. See set a PostgreSQL baseline.

• breg logs, and bregctl doctor reports under a new advisories list, value-free PostgreSQL advisories: the connection numbers one replica’s pool is compared with, a warning when that pool may take more than half of the usable connections, warnings when autovacuum or track_counts is off, and a note when pg_stat_statements is not installed or not loaded through shared_preload_libraries. Advisories never refuse startup or change doctor’s exit status, and need no extra grant. See deploy a registry.

• Breaking audit change: all six runtimes use the shared per-process file or stdout writer. Documented rotation, retention, shipping to append-only storage, and the mutation crash gap. Removed procedures for the retired audit verification, export, and prune commands. See Base Registry Engine audit retention, Evidence audit, and audit upgrades.

• BREAKING: published Base Registry Engine packages now carry the shared SHA256SUMS envelope. bregctl package reports its packageDigest and can add a hash-covered REVISION with --revision. breg verifies every listed file at startup in addition to the existing BReg signatures and deployment bindings, and package.expectedDigest can pin the shared digest. Rebuild old package directories with bregctl package before starting this version.

• BREAKING: evidencectl package now publishes one environment-neutral package directory with SHA256SUMS and an optional hash-covered REVISION; it no longer copies runtime.yaml into the output. Evidence Gateway verifies every listed file at startup and package.expectedDigest pins the package digest. The separate Evidence bundle and runtime revisions are removed, while each requirement’s package-derived configurationRevision remains. The retired evidencectl build spelling is refused with evidencectl package as the fix.

• evidence check --require-runtime-dependencies and evidence serve name the fault that stopped a Transit signer from initializing, after the unchanged evidence: runtime signing initialization failed: prefix: no answer on the Unix socket, a refused key read, a provider server error such as a sealed provider, a malformed response, a key whose custody is unsafe, a keyVersion above the key’s latest_version or below its min_encryption_version, a public key that is not the governed one, or a failed self-test. No cause carries a path, provider response, or key material. See build and activate the successor.

• An Evidence access-token issuer that serves its key set under a private certificate authority can be trusted through a named tlsTrustProfile on the bundle’s authentication block, bound in runtime.yaml exactly like a source’s profile. The CA is trusted beside the system roots for the jwksUri connection alone, hostname verification stays on, and a local HTTP jwksUri cannot name a profile. A profile bound on one side only is refused, and evidence check --require-runtime-dependencies fetches the key set through it before the listener binds. See an issuer behind a private CA.

• evidencectl doctor --runtime-config <file> --without-audit-lock, and the runtime’s evidence check --require-runtime-dependencies --without-audit-lock, check a candidate staged beside the Evidence instance it will replace. Without the option the check opens the audit destination as startup does, so it refuses while that instance holds the destination’s single-writer lock, and the refusal now names the option. With it, the audit hash key is checked as startup checks it, and the audit directory and files are checked for ownership, mode, write access, and a complete final entry, without taking the lock. A second writer is not detected; the JSON proofBoundary says so. See evidencectl.

• BREAKING: evidencectl refuses a derivation whose answer reads a fact its question’s source does not declare, as evidence.authoring.derivation-fact-undeclared against the derivation file. The declared facts are an inline operation’s source.facts[].name, or the properties of a referenced source’s closed factSchema. check, test, package, source diff, and source update all refuse, as do the compatibility spellings fixtures run and build, so a Base Registry Engine (BReg) field rename that a derivation still reads under its old name is refused before source update installs it or a candidate is packaged. The check reads the project, not the running registry: a field renamed in a registry that already serves a deployed candidate still fails every request that reads it while /ready reports ready, so change the registry and deploy the rebuilt candidate together. Only literal reads such as facts["status"] and facts.status are checked, and a ?? fallback between names passes when any of them is declared. See evidencectl.

• BREAKING: bregctl test --baseline-runtime-config rehearses the successor migration before it writes a receipt. It rebuilds the active package’s schema from its signed sources on the disposable test database, runs the migration in apply order, requires the candidate schema, and rolls back. A plan that used to fail only at apply now fails test, so package cannot sign it, and a predecessor this bregctl cannot rebuild is refused as migration.rehearsal.baseline_unavailable or migration.rehearsal.baseline_not_reproducible. The rehearsal runs over empty tables, so it does not prove data-dependent steps. A failure reports the SQLSTATE and the object names, never the PostgreSQL message. See test and package the successor.

• BREAKING: when PostgreSQL refuses a statement after bregctl apply began maintenance, the report is apply.migration.statement_failed instead of apply.migration.failed, and its message names the SQLSTATE, its class, and the table, column, or constraint PostgreSQL reported, never the PostgreSQL message or a stored value. registry-breg reports it as MigrationError::StatementFailed, from the new PostgresKernelError::Statement variant, so an exhaustive match on either enum needs the new arm; PostgresFailure is exported from registry_breg::postgres under every feature set. A lost connection, including a session the server ended (SQLSTATE class 08, 57P01 to 57P05, 25P03), still reports apply.migration.failed, while a compiler or reviewed statement that times out is a refused statement with SQLSTATE 57014. The target stays pinned as before. See troubleshooting.

• BREAKING: bregctl history rebaseline no longer refuses a registry holding more than 1,000 live rows. It verifies every live row against its journal head in pages of 1,000 inside one transaction, so a registry of any size can regain snapshot coverage after an erasure. The codes history.rebaseline.live_rows.budget_exceeded and field_encryption.erase_history.rebaseline.live_rows_budget_exceeded are gone, and so are HistoryRebaselineError::LiveRowBudgetExceeded and MAX_REBASELINE_LIVE_ROWS in registry-breg. The run holds every entity table exclusively, reads included, until it commits, so a larger registry means a longer read and write outage: size a maintenance window from a rehearsal. See restore snapshot coverage after an erasure.

• Raising a text field’s maxLength is a compatible additive change, field_length_widened, applied live: the successor replaces the column’s length check and validates the stored rows, with no reviewed migration. Revisions recorded under the lower limit stay readable, and an action over the entity stays additive as action_target_fields_widened. A string field’s maxLength is its column type, so raising it still needs a reviewed migration. See review and apply changes.

• Lowering a string field’s minLength under the same maxLength is also field_length_widened, applied live: the successor replaces the column’s minimum check, or drops it when the minimum falls to 0, with no reviewed migration. Revisions recorded under the higher minimum stay readable, and an action over the entity stays additive. Raising a minLength, changing a string field’s maxLength, and widening a decimal still need a reviewed migration. See review and apply changes.

• bregctl diff reports every removed field or entity as diff.history.removed_values_retained. Removing one from the package drops the live column or table, but the values stay in every revision snapshot recorded before the change and in every database backup; only bregctl history erase removes them, whole revisions of one record at a time. See review and apply changes.

• BREAKING: a reviewed chunked_backfill step now appends one history revision for every row each chunk changes, in the same commit as the chunk, so snapshot and as-of reads agree with the backfilled rows. Its chunkSize cap falls from 10,000 to 1,000, and its SQL must be a single UPDATE of the declared entity that names no record metadata column, uses no Unicode-escape identifier or string, and names no other statement word outside comments and plain string literals; the journal also refuses a step that changed created_at or updated_at. A plan outside those limits that test and package used to accept is now refused, and test reports a journaled step whose SQL the history journal refuses as migration.rehearsal.history_step_refused. See write a reviewed migration descriptor.

• Base Registry Engine (BReg) reports an accepted review whose result lookup answers an empty 404 as recovery.code: result-unknown-to-authority instead of leaving the code empty. The result poller serves a review that has a pending webhook completion first and one its authority no longer knows last, and a pending completion makes its review due at once. The new bregctl review-recovery resubmit submits the exact retained review request again under its original idempotency key, and bregctl review-recovery close stops waiting on a review the authority will never answer, reporting operator-closed. See change an active registry.

• BREAKING: Evidence Gateway reads runtime.yaml through the shared runtime configuration loader and declares its access-token issuer and audit key through the shared blocks. The runtime file now opens with apiVersion: registry.registrystack.org/evidence-runtime/v1alpha1 and kind: EvidenceRuntimeConfig instead of version: 1; bundleDirectory is package.root, with an optional package.expectedDigest pin; and listener.bindHost with listener.port is one listener.bind: host:port value, as it is for metricsListener. secretProviders.environment: {} enables secret:env/NAME references beside secret:file/name, and runtime string values accept ${VAR} outside secret references and secretProviders, while a ${...} expression in the governed bundle is refused with the field that holds it. In the governed bundle, the flat authentication fields move under authentication.oidc, kind: oidc-access-token is dropped, the one-entry audiences list is a single audience, jwksUri is jwksSource: {kind: uri, uri: ...}, and audit.hashSecretRef is audit.hashKeyRef; audit.hashKeyVersion is unchanged. Every subcommand that reads the runtime file takes the required --runtime-config FILE after the subcommand; the global --runtime flag, the REGISTRY_EVIDENCE_RUNTIME variable, and the default path are gone, and the container image passes the flag in its default command. A removed key, flag, or variable is refused with the name of its replacement. To migrate, rewrite the project’s governance.yaml and runtime.yaml with the new keys, rebuild the candidate with the matching evidencectl, and replace --runtime FILE with <subcommand> --runtime-config FILE in service definitions. See configure Evidence Gateway.

• BREAKING: Registry Casework reads runtime.yaml through the shared runtime configuration loader and declares its secret providers, database, listener bind, OpenID Connect issuer and clients, and audit key through the shared blocks. The runtime file may not pass through a symbolic link and is at most 1 MiB. ${VAR}, ${VAR:-default}, and ${VAR:?message} are substituted in string values after parsing; an expression in a field ending in Ref or under secretProviders is refused, and one in casework.yaml is refused by the runtime and by caseworkctl check. listener.bind is required. authentication.oidc.issuer must be an https URL without credentials, query, or fragment, with plain http accepted only on an IPv4 loopback host under development-loopback, and audience is at most 512 characters. Under operator-controlled-upstream, authentication.oidc.allowedClients must name at least one client, because an empty list admits every client the issuer verifies; development-loopback still accepts an empty list. authentication.oidc.jwksUri is removed: declare jwksSource with kind: uri and the same URL as uri. audit.hashKeyRef must be an exact secret reference. To migrate, add listener.bind if it was omitted, list the admitted clients in allowedClients for a production deployment, replace jwksUri, and move any environment expression out of casework.yaml. See configure the runtime.

• BREAKING: Base Registry Engine reads runtime.yaml through the shared runtime configuration loader and declares its OpenID Connect issuer, audit key, listeners, and secret providers through the shared blocks. breg takes the runtime file as --runtime-config FILE; --config is refused with the replacement named, bregctl request-retention cleanup-attachments no longer accepts its --config alias, and the container image passes the new flag in its default command. ${VAR}, ${VAR:-default}, and ${VAR:?message} are substituted in string values after parsing, so a substituted value is always text and never a number, boolean, or YAML structure; a ${...} expression in a field ending in Ref or under secretProviders is refused as runtime_config.substitution_in_reference, and one in the authored project or module files is refused as source.environment_expression. An empty YAML scalar is now null rather than an empty string, so quote "" where an empty string is meant. authentication.oidc.issuer must be an https URL without credentials, query, or fragment, with plain http accepted only on an IPv4 loopback host, audience is at most 512 characters, and jwksSource gains kind: uri beside discovery and static. A file missing apiVersion or kind is refused as runtime_config.invalid_api_version or runtime_config.invalid_kind. To migrate, replace --config FILE with --runtime-config FILE in service definitions and write any number or boolean that came from a variable directly in the file. See deploy a registry.

• BREAKING: Registry Relay reads runtime.yaml through the shared runtime configuration loader. The file now opens with apiVersion: registry.registrystack.org/relay-runtime/v1alpha1 and kind: RelayRuntimeConfig; server.bind is listener.bind, packagePath is an absolute package.root with an optional package.expectedDigest pin, and authentication.issuer is authentication.oidc with issuer and a jwksSource of kind: discovery or kind: uri. A secret:file/ reference resolves under the declared secretProviders.file.root instead of beside the runtime file, and secret:env/ needs secretProviders.environment. relay check and relay serve take the required absolute --runtime-config FILE; the --runtime flag, the RELAY_RUNTIME variable, and the default path are gone. A removed key is refused with the name of its replacement, and an environment expression such as ${VAR} in the authored registry.yaml is refused as contract.environment_expression. The Registry Relay retirement decision records the current status of this surface.

• BREAKING: Registry Discovery reads runtime.yaml through the shared runtime configuration loader. The file now opens with apiVersion: registry.registrystack.org/discovery-runtime/v1alpha1 and kind: DiscoveryRuntimeConfig instead of schemaVersion, and listener.address is listener.bind. The binary takes --runtime-config FILE, an absolute path free of symbolic links, in place of --runtime, and the container image passes it in its default command. A removed key is refused with the name of its replacement. See configure Registry Discovery.

• BREAKING: Registry Render reads runtime.yaml through the shared runtime configuration loader. The file now opens with apiVersion: registry.registrystack.org/render-runtime/v1alpha1 and kind: RenderRuntimeConfig; server.bind is listener.bind and is required, server.shutdownGraceSeconds is listener.shutdownGraceSeconds, bundle.path is package.root, and secret providers are declared under secretProviders. Paths, including audit.path, must be absolute, and a removed key, among them audit.directory, audit.integrityKeyRef, and audit.maxSegmentBytes, is refused with the name of its replacement. serve, healthcheck, and check take --runtime-config FILE, and none reads a default path or the REGISTRY_RENDER_RUNTIME variable. An environment expression such as ${VAR} in the authored bundle manifest.yaml is refused with the field that holds it. See run Registry Render in serve mode.

• BREAKING: Registry Scheduling reads runtime.yaml through the shared runtime configuration loader. authentication.oidc.jwksUri is removed and refused with the name of its replacement, a jwksSource of kind: uri; listener.bind is required and no longer defaults to a loopback port; the file and every configured path are refused when they pass through a symbolic link; and an environment expression such as ${VAR} in the authored scheduling.yaml, records, or fixtures is refused with the field that holds it. runtime.yaml string values accept ${VAR} outside *Ref fields and secretProviders, and an optional package.expectedDigest pins the policy the runtime starts on.

• Base Registry Engine (BReg) adds the import operation and import authorities, so a governed entity can take a bulk load without granting batch, create, or patch to a direct-write profile. import is create-only, is served only through ingestion runs, and is not a direct write for change control, so change_control.direct_write_grant accepts it on a controlled entity. An import run is created only inside an open import authority that an operator opens with bregctl import-authority open for one entity and one profile, with a window of at most 30 days, a maximum item count, and optional pinned input digests. Every chunk counts against the authority; closing it, its expiry, its exhaustion, or a successor package activation stops the run with blockedReason importAuthorityClosed. Opening, closing, expiry, exhaustion, and supersession each append an audit record, and every run audit record carries importAuthorityId. The compiler refuses import without entity batch bounds (import.batch_bounds.required), without an authenticated principal (import.principal.required), and beside a batch grant on the same entity (import.batch.redundant). bregctl data validate reports the source’s inputDigest for pinning; the digest is a label the client announces with the run and the server records, never recomputed over the written items. The runtime installs a new internal table and a run column on its next apply. See load records through an import window.

• BREAKING: the ingestion-run blockedReason gains the value importAuthorityClosed, and the Rust BRegIngestionBlockedReason enum gains ImportAuthorityClosed; a client that matched the only previous value exhaustively must handle the new one. The attempt that blocks a run on its authority is recorded as lastAttempt.outcome importAuthorityClosed, not bindingChanged, so the Rust BRegIngestionAttemptOutcome enum and the Node.js BRegIngestionAttemptOutcome type gain the same value. The ingestion.run_blocked problem detail now reads “The ingestion run is blocked and refuses further chunks.” because the run’s blockedReason, not the detail, names the cause.

• BREAKING: bregctl data import reports a run creation the server refuses with 412 as data.import.ingestion_run.import_authority_required when the grant is import, and data.import.ingestion_run.precondition_failed otherwise, instead of data.import.operation.refused. A blocked run reports data.import.ingestion_run.import_authority_closed or data.import.ingestion_run.blocked with its reason.

• BREAKING: the Base Registry Engine runtime refuses to serve a database that is not the one its instance claim names. The claim records the PostgreSQL system identifier and database object identifier at the first apply, so a logically restored copy (pg_dump and pg_restore) or a registry moved by pg_upgrade no longer starts: breg refuses with the new StartupError variant InstanceClaimMismatch, GET /ready answers 503, and bregctl doctor reports startup.instance_claim.mismatch. This keeps a restored copy from serving beside its original as a divergent writer of the same registry. Once the original is stopped for good, the new command bregctl instance-claim adopt --acknowledge-original-retired moves the claim to the copy with a raised epoch and, once that commits, appends an audit entry naming the previous and the adopted claim; bregctl instance-claim status reports whether the claim matches. A physical copy (base backup, point-in-time recovery, snapshot, or promoted replica) keeps its identity and is not refused. The claim is recorded only into a fresh database, one with no committed revision and no commit head, so an existing registry records none when its next apply installs the new internal table: run instance-claim adopt once after that apply, before starting the server. Adopting also supersedes every open import authority, with its own audit record, so a restored backup brings no authority back. On a managed PostgreSQL service that withholds pg_control_system(), the claim compares the database object identifier alone. The claim is checked at startup and on readiness, not per request. A Rust match over StartupError must handle the new variant. See after a logical restore.

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 monitor and recover.

• 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 monitor and recover.

• 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 control access and reads.

• 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 how Evidence works 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 hook 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 Actions and Proposals, modeling patterns, and control access and reads.
• 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 (retired), 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