Registry stack documentation: machine-readable Markdown.
Index of all pages: https://docs.registrystack.org/llms.txt
Full corpus: https://docs.registrystack.org/llms-full.txt

# Review changes before updating a registry

> Author and inspect a Base Registry Engine (BReg) change request whose review is owned by Registry Casework, then verify that source application remains separately authorized.

import QuickstartMeta from '../../../components/QuickstartMeta.astro';

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.

<QuickstartMeta
  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 project', 'A shell and an editor']}
/>

## Copy the maintained example

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

```sh
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:

```yaml
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.

{/* Evidence: products/breg/acceptance/asset-site-placement-change-requests/registry.yaml;
    crates/registry-breg/src/change_request.rs;
    crates/registry-breg/src/request_workflow.rs. */}

## Inspect the compiled boundary

```sh
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:

```yaml
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](../review-breg-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](../../configure/breg-change-control/) for the
complete authoring shape and [Base Registry Engine API reference](../../reference/breg-api/#change-requests)
for the four source actions and review projection.