Review changes before updating a registry

Base Registry Engine (BReg) owns the proposal, its frozen effects, source authorization, application guards, and the application receipt. Registry Casework owns reviewer stages and the review result. This tutorial checks the BReg half of that boundary before you connect the two services.

Outcome

A checked BReg request type with a frozen external-review binding and separately authorized application.

Time

About 15 minutes

Level

Local authoring

Prerequisites

bregctl from the same Registry Stack release as your projectA shell and an editor

Copy the maintained example

From a Registry Stack checkout, copy the asset placement example:

mkdir -p tutorial-work
cp -R products/breg/acceptance/asset-site-placement-change-requests \
  tutorial-work/asset-corrections
bregctl check tutorial-work/asset-corrections

The request entity declares the effect BReg will freeze and the logical review authority and policy Casework will evaluate:

changeRequest:
  effects:
    - target: {fromField: placement}
      operation: patch
      set:
        site: {fromField: proposed-site}
  review:
    authority: casework
    policyId: asset-placement-correction
  onApproved:
    mode: manual
  retention:
    mode: operator_erase

review is part of the immutable proposal binding. It is not a local BReg stage declaration. onApproved.mode: manual means an ordinary caller must still hold the current apply_request grant and every required applyTargets grant after BReg has reconciled an exact approved result.

Inspect the compiled boundary

bregctl --format json explain change-requests tutorial-work/asset-corrections \
  > tutorial-work/change-requests.json

Inspect tutorial-work/change-requests.json. The request has only four source lifecycle actions: submit_request, revise_request, cancel_request, and apply_request. It also carries the frozen review requirement, approved-application mode, effects, target entities, and application grants. It has no BReg reviewer action or stage route.

Submission freezes request values, target identities and revisions, the effect digest, the review requirement, and application preconditions. A later package cannot silently change that proposal.

Check source roles

The example separates these BReg roles:

• The submitter creates and edits its own draft, then submits, revises, or cancels it.
• A request reader may receive review_state when its readableRequestFields grants that disclosure. Reading review state does not grant a Casework decision or BReg application.
• The applier holds apply_request and the required applyTargets. BReg rechecks both at use.

Casework policy defines reviewer eligibility, stages, approval counts, and independence. Configure that policy in Casework rather than adding reviewer operations to BReg access profiles.

To use an automatic source application, change the authored binding to:

onApproved:
  mode: automatic
  executor: corrections-applier

The BReg runtime must separately bind corrections-applier to an ordinary credential and source profile. Automatic application follows the same authenticated HTTP action and guards as manual application. A completion notification is never authority to write the target.

Continue with the combined journey

Follow Review Base Registry Engine changes in Casework to configure the authority client, submit a proposal, decide it under Casework policy, and apply it at the source. Use Declare change requests and actions for the complete authoring shape and Base Registry Engine API reference for the four source actions and review projection.