diff --git a/docs/site/src/content/docs/tutorials/build-a-breg-production-candidate.mdx b/docs/site/src/content/docs/tutorials/build-a-breg-production-candidate.mdx
index 82ec68626..eb6fa5ecd 100644
--- a/docs/site/src/content/docs/tutorials/build-a-breg-production-candidate.mdx
+++ b/docs/site/src/content/docs/tutorials/build-a-breg-production-candidate.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-04"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - data publisher
@@ -28,7 +28,7 @@ from there.
   outcome="A package built from your project, signed with a local key, and accepted by bregctl verify under a trust anchor you wrote."
   time="About 30 minutes"
   level="Production build with synthetic data and local keys"
-  prerequisites={['bregctl 0.26.1 from Create and query your first registry', 'Docker', 'OpenSSL 3']}
+  prerequisites={['The bregctl from Create and query your first registry', 'Docker', 'OpenSSL 3']}
 />
 
 ## Before you start
@@ -152,7 +152,7 @@ package, or a repository. They exist for this exercise and are deleted in the cl
 
 The runtime connects to PostgreSQL over TLS only, and the schema test uses the same connection code,
 so the container needs a server certificate. Create a small certificate authority and a certificate
-for `localhost`, then start the PostgreSQL 17 image the quickstart launcher uses, on port 5433 so it
+for `localhost`, then start a PostgreSQL 17 container on port 5433 so it
 stays clear of a PostgreSQL you may already run:
 
 ```sh
diff --git a/docs/site/src/content/docs/tutorials/extend-a-registry-with-a-module.mdx b/docs/site/src/content/docs/tutorials/extend-a-registry-with-a-module.mdx
index 4712d5ca4..f43db293e 100644
--- a/docs/site/src/content/docs/tutorials/extend-a-registry-with-a-module.mdx
+++ b/docs/site/src/content/docs/tutorials/extend-a-registry-with-a-module.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-07"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - data publisher
@@ -73,15 +73,14 @@ Authoring check passed.
 ```
 
 This is the project the first tutorial started as a registry, so the entity, fields, and profiles are
-the ones you used over HTTP: `registry.yaml`, one module under `modules/`, `tests/journeys.yaml`,
-`dev-clients.yaml`, `runtime.example.yaml`, and a `README.md` that lists them.
+the ones you used over HTTP, in the files [init wrote](../first-breg/#what-init-wrote).
 The `revision` line is the digest of the compiled project; it changes with every edit you make.
 
 A finding is advice the compiler attaches to a result that succeeded: an error stops a command, a finding does not.
 The first says the `operator` profile can list every row, which is intended for a registry-wide operations team,
-and the second says the `evidence-source` profile can look up any record by its code;
-the project's `record-reader` profile shows the claim-bound row restriction that closes either one.
-Every command in this tutorial repeats both findings, so treat them as expected and read past them to the result.
+and the second says the `evidence-source` profile can look up any record by its code.
+Every command in this tutorial that succeeds repeats both findings, so treat them as expected and read past them to the result.
+A check that is refused prints its errors instead, and you will meet one when you change the module.
 
 {/* Evidence: crates/registry-bregctl/src/lib.rs, init_files() and check(); crates/registry-breg/src/access.rs. */}
 
@@ -89,26 +88,19 @@ Every command in this tutorial repeats both findings, so treat them as expected
 
 A module is a separate file that contributes to the model, so a reusable part of a registry can be reviewed
 and versioned apart from the project that adopts it.
-Open `tutorial-work/project/modules/record-notes/module.yaml`.
-Written out as block mappings (the file keeps each field on one line), it declares one optional field on the
-entity the project owns:
+Open `tutorial-work/project/modules/record-notes/module.yaml` and find its version and the one field it
+declares on the entity the project owns:
 
 ```yaml
-id: record-notes
 version: 0.1.0
-extendEntities:
-  - entity: record
-    fields:
-      - id: internal-note
-        type: string
-        maxLength: 500
-        classification: internal
+```
+
+```yaml
+      - {id: internal-note, type: string, maxLength: 500, classification: internal}
 ```
 
 A field without `required: true` is optional, so existing records stay valid and a create may omit it.
 Its classification matches the entity's default, `internal`.
-A more sensitive value such as `restricted` adds a further finding, `access.profile.higher_classification`,
-once a grant exposes the field; it asks you to confirm the profile's scope and purpose first.
 
 Now open `tutorial-work/project/registry.yaml` and find the `modules` entry at the end of the file:
 
diff --git a/docs/site/src/content/docs/tutorials/query-a-spatial-registry-from-qgis.mdx b/docs/site/src/content/docs/tutorials/query-a-spatial-registry-from-qgis.mdx
index 329d6bbb3..e5b899336 100644
--- a/docs/site/src/content/docs/tutorials/query-a-spatial-registry-from-qgis.mdx
+++ b/docs/site/src/content/docs/tutorials/query-a-spatial-registry-from-qgis.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-07"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - data publisher
@@ -127,11 +127,10 @@ display to **Extents** and confirm that the longitude span is less than `0.24` d
 latitude span is less than `0.19` degrees.
 
 The `installation-map-reader` profile caps a bounding box at `0.25` longitude degrees by `0.20`
-latitude degrees. The cap limits how much of the map one query may ask for. It does not decide
-which records you may see: that is the profile's row boundary, which compares each record's
-`zone` with the `service_zones` claim in the installation credential. The smaller view leaves
-room for QGIS decimal serialization and for canvas aspect-ratio changes. A world view exceeds the
-cap and Base Registry Engine refuses the query with `query.invalid`.
+latitude degrees, and a world view exceeds it, so Base Registry Engine refuses the query with
+`query.invalid`. The smaller view leaves room for QGIS decimal serialization and for canvas
+aspect-ratio changes. The cap limits how much of the map one query may ask for, not which records
+you may see; that is the profile's row boundary, which you meet in the next steps.
 
 {/* Evidence: products/breg/acceptance/spatial-service-sites/registry.yaml;
     crates/registry-breg/src/query.rs, parse_bbox();
@@ -180,15 +179,11 @@ messages. The quickstart creates the secret file with owner-only permissions.
 QGIS draws Point features near the map center. Press `F6` to open the attribute table. The
 table includes `id`, `label`, `mapLabel`, `nativeId`, `serviceKind`, `siteCode`, and `zone`.
 
-The installation credential carries a `service_zones: central` claim, so the collection returns
-only records whose `zone` is `central`. The layer is read-only, requests at most 25 records per
-page, and sends the visible extent as a bounding box. Base Registry Engine applies the same scope,
-purpose, row, and field rules to the QGIS-compatible route as it applies to native reads.
-
-The bounding box is a filter inside that row boundary, not the boundary itself. If you leave
-**Only request features overlapping the view extent** off, QGIS sends no bounding box and pages
-through every record the row boundary allows, 25 at a time; the server allows at most 100 records
-per page on this collection.
+Every `zone` value is `central`: the installation credential carries a `service_zones: central`
+claim, and the profile's row boundary returns only records whose `zone` matches it. The bounding
+box is a filter inside that boundary, not the boundary itself. Base Registry Engine applies the
+same scope, purpose, row, and field rules to the QGIS-compatible route as to native reads; the
+[API reference](../../reference/breg-api/#spatial-adapter) covers the route and its paging limits.
 
 {/* Evidence: crates/registry-breg/src/api/gis.rs, collections(), collection(), items(),
     authorize_gis_collection(), parse_items_query() and query_options();
@@ -272,8 +267,8 @@ Imported the input. 1 item committed.
 Run the block as one unit: every token the spatial quickstart mints, including the operator token
 this block requests, expires after 60 seconds. The checkpoint records each committed chunk, so an
 interrupted import resumes without sending a completed chunk again. If you run the import a
-second time with the same checkpoint, it sends nothing and reports `0 items committed` with
-`complete` at `true`. The operator token stays in an owner-only file and is never copied into QGIS.
+second time with the same checkpoint, it sends nothing and prints the same summary, because the
+counts come from the checkpoint. The operator token stays in an owner-only file and is never copied into QGIS.
 
 {/* Evidence: crates/registry-bregctl/src/lib.rs;
     products/breg/quickstart/support/quickstart.py, store_token();
diff --git a/docs/site/src/content/docs/tutorials/query-breg-client.mdx b/docs/site/src/content/docs/tutorials/query-breg-client.mdx
index b7a70b8d1..6c0fb083e 100644
--- a/docs/site/src/content/docs/tutorials/query-breg-client.mdx
+++ b/docs/site/src/content/docs/tutorials/query-breg-client.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-07"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - consumer or verifier
@@ -16,14 +16,12 @@ standards_referenced:
 
 import QuickstartMeta from '../../../components/QuickstartMeta.astro';
 
-This tutorial needs a registry on Registry Stack v0.26.1 or later and a client package at exactly
-that registry's version. The unified client packages start at v0.26.1: against a v0.26.0 registry
-there is no Base Registry Engine client package to install. The unified Registry Stack client gives
-an application one method for each Base Registry Engine operation, in Python and in Node. In this
-tutorial you install the published package, read the record you created in the first tutorial,
-create a record with an idempotency key, page through the collection with a continuation, and
-inspect a refused write. Every step shows both languages; follow the one your application uses, or run both against
-the same registry.
+The unified Registry Stack client gives an application one method for each Base Registry Engine
+operation, in Python and in Node. In this tutorial you install the published package at your
+registry's version, read the record you created in the first tutorial, create a record with an
+idempotency key, page through the collection with a continuation, and inspect a refused write.
+Every step shows both languages; follow the one your application uses, or run both against the
+same registry.
 
 <QuickstartMeta
   outcome="A Python program and a Node program that read, page, and write your local registry through the unified client and handle a refusal explicitly."
@@ -59,6 +57,7 @@ Success prints nothing. The file is readable only by your user; the programs rea
 
 ## Install the client
 
+The package version must equal the registry's, and the packages start at v0.26.1.
 Work in a directory of its own and read the version from the `breg` binary rather than typing it:
 
 ```sh
@@ -273,7 +272,9 @@ while True:
   }
 ```
 
-The run adds one line per record, across two pages:
+The run adds one line per record, across two pages.
+A list without `orderby` is sorted by the identifier the registry assigned, so the two lines come
+in either order:
 
 ```text
 DEMO-002
@@ -322,12 +323,9 @@ problem
 mutation.conflict
 ```
 
-Other kinds arrive the same way. The ones you are most likely to meet are `transport` when the
-connection or the exchange failed below HTTP, `configuration` and `invalid_request` when the client
-refused an input before sending anything, `metadata_selection` when a binding could not be
-selected, and `protocol` when a response violated the contract. Every kind carries a message
-(`str(error)` in Python, `error.message` in Node); a kind that comes from a response also carries
-the trace identifier to quote when you ask the registry operator about it. The
+Other kinds arrive the same way, each with a message (`str(error)` in Python, `error.message` in
+Node), and a kind that comes from a response also carries the trace identifier to quote when you
+ask the registry operator about it. The
 [Registry Stack client API reference](../../reference/client-api/#breg-error-contract) names
 every kind the bindings raise and the members each one sets.
 
@@ -354,7 +352,8 @@ inspect a refused write through one error type.
 | Symptom | Cause | Fix |
 | --- | --- | --- |
 | `pip` or `npm` finds no matching version | The registry is older than v0.26.1, or `version` does not match `breg --version` | Install a v0.26.1 or later release, start the registry with it, and reinstall at its exact version |
-| `KeyError: 'REGISTRY_URL'`, or a `TypeError` naming the `path` argument | `REGISTRY_URL` or `REGISTRY_TOKEN_FILE` is not set | Prefix the command with both assignments as shown in [Construct a client and probe the registry](#construct-a-client-and-probe-the-registry) |
+| `KeyError: 'REGISTRY_URL'` in Python, or `configuration` in Node | `REGISTRY_URL` is not set | Prefix the command with both assignments as shown in [Construct a client and probe the registry](#construct-a-client-and-probe-the-registry) |
+| `KeyError: 'REGISTRY_TOKEN_FILE'` in Python, or a `TypeError` naming the `path` argument in Node | `REGISTRY_TOKEN_FILE` is not set | Prefix the command with both assignments |
 | `problem` with status `401` and code `authentication.refused` | The token is older than five minutes | Renew it with the `mint token` command in [Before you start](#before-you-start) and rerun |
 | `transport` with a `connect` transport kind | The registry is not running | Start it again with the first tutorial's `bregctl dev` command and renew the token |
 | `problem` with status `400` and code `query.invalid` | A filter names a field the profile does not allow | Filter on `code` or `status` only |
diff --git a/docs/site/src/content/docs/tutorials/review-registry-changes.mdx b/docs/site/src/content/docs/tutorials/review-registry-changes.mdx
index 8497bed00..cf964b05a 100644
--- a/docs/site/src/content/docs/tutorials/review-registry-changes.mdx
+++ b/docs/site/src/content/docs/tutorials/review-registry-changes.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-07"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - data publisher
@@ -76,7 +76,7 @@ It does not leave the change-request example running as an HTTP service.
     crates/registry-breg/src/fixtures.rs;
     crates/registry-breg/src/change_request.rs. */}
 
-## 1. Check your first request type
+## Check the example project
 
 Copy the supplied example into a working directory so your edits leave the original unchanged,
 then check it:
@@ -87,9 +87,10 @@ cp -R products/breg/acceptance/asset-site-placement-change-requests tutorial-wor
 bregctl check tutorial-work/asset-corrections
 ```
 
-The check succeeds, prints the compiled configuration's digest, and lists 26 findings under four
+The check passes, prints the compiled configuration's digest, and lists 26 findings under four
 codes.
-A code reported against more than one path states its sentence once and lists the paths beneath it:
+A code reported against more than one path states its sentence once and lists the paths beneath it;
+the first group and the summary line are kept below, the other three groups omitted:
 
 ```text
 Authoring check passed.
@@ -106,50 +107,25 @@ Authoring check passed.
              entities[id=asset-site].accessProfiles[id=asset-operator].requiredScopes
              entities[id=asset-site].accessProfiles[id=site-planner].requiredScopes
              entities[id=inspection-event].accessProfiles[id=asset-operator].requiredScopes
-  finding  access.profile.unrestricted_collection  10 paths
-           this profile can list all rows, subject only to query bounds; caller filters
-           are not authorization. Add a claim-bound row restriction or review this
-           registry-wide access
-             entities[id=asset-item].accessProfiles[id=asset-operator].rowBoundaries
-             entities[id=asset-item].accessProfiles[id=site-planner].rowBoundaries
-             entities[id=asset-placement].accessProfiles[id=asset-operator].rowBoundaries
-             entities[id=asset-placement].accessProfiles[id=correction-submitter].rowBoundaries
-             entities[id=asset-placement].accessProfiles[id=site-planner].rowBoundaries
-             entities[id=asset-site].accessProfiles[id=asset-operator].rowBoundaries
-             entities[id=asset-site].accessProfiles[id=correction-submitter].rowBoundaries
-             entities[id=asset-site].accessProfiles[id=site-planner].rowBoundaries
-             entities[id=inspection-event].accessProfiles[id=asset-operator].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-reviewer].rowBoundaries
-  finding  access.profile.unrestricted_rows  4 paths
-           this profile has no claim-bound row restriction for its granted operations;
-           requestVisibility owner limits request reads only, and other lifecycle rules
-           still apply. Review this registry-wide access
-             entities[id=asset-item].accessProfiles[id=correction-submitter].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-applier].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-submitter].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-supervisor].rowBoundaries
-  finding  access.target.unrestricted_rows  5 paths
-           this target grant has no claim-bound row restriction, within its configured
-           operation and field limits. Review this registry-wide target authority
-             entities[id=asset-placement].accessProfiles[id=asset-operator].requestPresence[requestType=placement-correction-request].rowBoundaries
-             entities[id=asset-placement].accessProfiles[id=site-planner].requestPresence[requestType=placement-correction-request].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-applier].applyTargets[entity=asset-placement].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-reviewer].reviewStages[stage=review].targets[entity=asset-placement].rowBoundaries
-             entities[id=placement-correction-request].accessProfiles[id=correction-supervisor].reviewStages[stage=final-approval].targets[entity=asset-placement].rowBoundaries
 
 0 errors, 26 findings.
 ```
 
 Findings are advisories, not failures.
-The example's `asset-operator` and `site-planner` profiles admit any authenticated caller with the
-right purpose and can list every row, and the correction submitter and reviewer can list every
-row they reach.
-The four correction profiles require scopes.
+The first code is about who may select a profile: `asset-operator` and `site-planner` declare no
+required scope, so any authenticated caller with the right purpose qualifies.
+Each `correction-` profile declares a scope of its own, which is why none of them appear in that group.
+The three remaining codes are about row authority instead.
+They name grants that hold no claim-bound row restriction, within the operations and fields each
+grant allows, and a grant that includes `list` can therefore list every row.
 Leave the findings as they are for this tutorial; `--deny-findings` turns them into failures when
 you want a project held to that bar.
+Every check that passes in this tutorial repeats them, so read past them to the summary line.
+A check that is refused prints its errors instead, and you will meet one at the end.
 
-You have a valid request type without writing server code.
-No database has changed yet.
+## Explain the workflow
+
+You have a valid request type without writing server code, and no database has changed yet.
 Ask the CLI to describe what it compiled:
 
 ```sh
@@ -187,84 +163,50 @@ request_revision final-approval Idempotency-Key,If-Match,proposalVersion,effectD
 The example requires one approval at each of two stages.
 Every action needs an `Idempotency-Key` and an `If-Match`; a decision or an apply also binds to
 the `proposalVersion` and `effectDigest` the caller read.
-The JSON file also lists the compiled effects, the planner and application policy, the grants of each role, and the request bounds.
-A planner is the script that computes a request's effects when they depend on the request's own
-content, declared in place of a fixed `effects` list; this example declares `effects`, so the JSON
-reports its planner `kind` as `declarative`.
-See [plan effects with a Rhai script](../../configure/breg-change-control/#plan-effects-with-a-rhai-script)
-for the alternative.
+The JSON file also lists the compiled effects, the planner, the grants of each role, and the request bounds.
+This example declares a fixed `effects` list, so the planner `kind` is `declarative`;
+[plan effects with a Rhai script](../../configure/breg-change-control/#plan-effects-with-a-rhai-script)
+is the alternative.
 
 {/* Evidence: crates/registry-bregctl/src/lib.rs, explain_change_requests;
     crates/registry-breg/src/rhai_planner.rs;
     products/breg/acceptance/asset-site-placement-change-requests/registry.yaml. */}
 
-## 2. Read the rule you are testing
+## Find the rule you are testing
+
+Open `tutorial-work/asset-corrections/registry.yaml` and find the `placement-correction-request`
+entity.
+Its `changeRequest` block declares one effect, a `patch` of the referenced placement's `site`, and
+the two stages the explanation listed:
+
+```yaml
+      review:
+        stages:
+          - {id: review, approvals: 1, excludeSubmitter: true}
+          - {id: final-approval, approvals: 1, excludeSubmitter: true}
+```
 
-Open `registry.yaml` in `tutorial-work/asset-corrections`.
-The `placement-correction-request` entity has its own fields: a placement reference, a proposed site,
-and a reason.
-The relevant configuration, expanded for readability, is:
+Submitting and approving a request store a proposal; only an apply carries out the effect.
+Now find the `asset-placement` entity above it:
 
 ```yaml
-changeRequest:
-  retention:
-    mode: operator_erase
-  effects:
-    - target:
-        fromField: placement
-      operation: patch
-      set:
-        site:
-          fromField: proposed-site
-  review:
-    stages:
-      - id: review
-        approvals: 1
-        excludeSubmitter: true
-      - id: final-approval
-        approvals: 1
-        excludeSubmitter: true
+    changeControl:
+      requiredFor: [patch]
 ```
 
-The request stores a proposal separately from the placement record.
-Its configured effect says which placement field changes when the request is applied.
-Submitting and approving the request do not apply that effect.
-`retention.mode` defaults to `retain`, which keeps every proposal version and refuses operator
-erasure.
-The example selects `operator_erase` so an operator can later erase the detail of a finished
-request with an explicit command; nothing is deleted on a schedule.
-
-The access profiles separate the work.
-Each grant lists the operations its role may perform on the request entity:
-
-| Profile | Operations | Responsibility |
-| --- | --- | --- |
-| `correction-submitter` | `create`, `get`, `patch`, `submit_request`, `revise_request`, `cancel_request` | Draft, edit, submit, and if asked, revise the request |
-| `correction-reviewer` | `get`, `list`, `approve_request`, `reject_request`, `request_revision` | Decide the `review` stage |
-| `correction-supervisor` | `get`, `approve_request`, `reject_request`, `request_revision` | Decide the `final-approval` stage |
-| `correction-applier` | `get`, `apply_request` | Apply the approved proposal to the placement |
-
-A reviewer's grant names the stages it may decide under `reviewStages`, with the placement fields
-it may see while deciding.
-The applier's grant names the placement under `applyTargets`.
-Each stage excludes the submitting principal from approving.
-That rule does not require a different person for every stage: access profiles and stage grants
-determine which other principals can approve.
-The example supplies different identities for the two reviewers.
-
-On `asset-placement`, `changeControl.requiredFor: [patch]` makes patching a controlled operation.
-The ordinary placement grants omit `patch`, and the generated API has no `PATCH` route for
-placements at all: the only way to change a placement's site is an applied request.
-Those grants carry `requestPresence` instead, so an operator reading a placement sees that a
-correction is pending.
+This makes patching a placement a controlled operation.
+The ordinary placement grants omit `patch`, so the only way to change a placement's site is an
+applied request, and you test that rule in the last step.
+The four `correction-*` profiles split the work between a submitter, a reviewer for the `review`
+stage, a supervisor for `final-approval`, and an applier;
+[split the roles across profiles](../../configure/breg-change-control/#split-the-roles-across-profiles)
+explains each grant and the `retention` mode the example selects.
 
 {/* Evidence: products/breg/acceptance/asset-site-placement-change-requests/registry.yaml;
-    products/breg/scripts/test-change-request-examples.sh;
     crates/registry-breg/src/request_workflow.rs;
-    crates/registry-breg/src/request_retention.rs;
-    crates/registry-breg/tests/postgres_change_requests.rs. */}
+    crates/registry-breg/src/request_retention.rs. */}
 
-## 3. Run the approval workflow
+## Start a disposable database
 
 In a second terminal, at the root of the same clone, start the local quickstart.
 You are borrowing its disposable PostgreSQL cluster, which the runner reaches over TLS with the
@@ -291,8 +233,9 @@ Wait for this line, then leave the terminal running:
 Base Registry Engine generic quickstart is ready.
 ```
 
-Return to your first terminal.
-Create a Python environment for the example runner's YAML support:
+## Run the approval workflow
+
+Return to your first terminal and create a Python environment for the example runner's YAML support:
 
 ```sh
 uv venv tutorial-work/venv
@@ -356,24 +299,9 @@ Open `tests/journeys.yaml` in your copy.
 A journey is a sequence of API calls with the status and fields expected from each response.
 This one creates an asset, two sites, and a placement, drafts the correction, submits it, collects
 both approvals, and applies it.
-On a running server, the same journey is this sequence of HTTP calls:
-
-| Journey steps | Caller | HTTP call |
-| --- | --- | --- |
-| Create the asset, both sites, and the placement | `asset-operator` | `POST /v1/records/assets`, `/v1/records/sites`, and `/v1/records/placements` |
-| Create and edit the draft request | `correction-submitter` | `POST /v1/records/placement-correction-requests`, then `PATCH /v1/records/placement-correction-requests/{id}` with the record's `ETag` |
-| Submit | `correction-submitter` | `POST /v1/records/placement-correction-requests/{id}/actions/submit` |
-| Approve the `review` stage | `correction-reviewer` | `POST /v1/records/placement-correction-requests/{id}/actions/stages/review/approve` |
-| Approve the `final-approval` stage | `correction-supervisor` | `POST /v1/records/placement-correction-requests/{id}/actions/stages/final-approval/approve` |
-| Apply | `correction-applier` | `POST /v1/records/placement-correction-requests/{id}/actions/apply` |
-
-Before each action, the journey gets the request as the next caller.
-The response's `data.request.actions[]` lists what that caller may do next, each with its `href`,
-its own `ifMatch`, and, for decisions and apply, the `proposalVersion` and `effectDigest` it binds
-to.
-The journey's `etagRef`, `proposalVersionRef`, and `effectDigestRef` take those values from the
-captured response, and a client making HTTP calls itself reads the same members.
-The record's ordinary `ETag` header edits the draft; it is not an action's `ifMatch`.
+Each action step names its caller's profile, the operation, and for a decision the stage.
+The routes behind those steps, and the `request.actions[]` members a client reads before each call,
+are in the [API reference](../../reference/breg-api/#change-requests).
 
 {/* Evidence: products/breg/quickstart/run.sh;
     products/breg/quickstart/support/quickstart.py, prepare;
@@ -383,7 +311,7 @@ The record's ordinary `ETag` header edits the draft; it is not an action's `ifMa
     crates/registry-breg/src/fixtures.rs;
     crates/registry-breg/src/request_workflow.rs. */}
 
-## 4. Make the second stage your own
+## Rename the second stage
 
 Rename `final-approval` to `operations-approval` in your copied `registry.yaml`, in two places:
 the stage's `id` and the `correction-supervisor` grant's `reviewStages` entry.
@@ -394,26 +322,17 @@ The step and capture identifiers can keep their original names.
 Your stage, grant, and journey step now agree on who approves what:
 
 ```yaml
-# Under changeRequest.review.stages:
-- {id: operations-approval, approvals: 1, excludeSubmitter: true}
+          - {id: operations-approval, approvals: 1, excludeSubmitter: true}
 ```
 
 ```yaml
-# The correction-supervisor grant:
-- entity: placement-correction-request
-  operations: [get, approve_request, reject_request, request_revision]
-  readableFields: [placement, proposed-site, reason]
-  reviewStages:
-    - stage: operations-approval
-      targets:
-        - {entity: asset-placement, readableFields: [site], rowBoundaries: []}
+        reviewStages:
+          - stage: operations-approval
 ```
 
 ```yaml
-# The approve-final-stage step in tests/journeys.yaml:
-request:
-  operation: approve_request
-  stage: operations-approval
+          operation: approve_request
+          stage: operations-approval
 ```
 
 Run the structural check and the database journey again:
@@ -434,7 +353,7 @@ For a new stage rather than a rename, you would also add its GET and approval st
     products/breg/acceptance/asset-site-placement-change-requests/tests/journeys.yaml;
     products/breg/scripts/test-change-request-examples.sh. */}
 
-## 5. Check that a direct-write bypass is refused
+## Check that a direct write is refused
 
 In your copied `registry.yaml`, find the `asset-operator` grant for `asset-placement`.
 Temporarily add `patch` to its operations:
@@ -447,10 +366,17 @@ operations: [create, get, list, patch]
 bregctl check tutorial-work/asset-corrections
 ```
 
-The check fails with `change_control.direct_write_grant` and the message
-`a controlled mutation operation cannot remain directly granted`.
+```text
+bregctl check refused.
+
+  error    change_control.direct_write_grant  entities[id=asset-placement].accessProfiles[id=asset-operator].operations
+           a controlled mutation operation cannot remain directly granted
+
+1 error, 0 findings.
+```
+
 This is an expected refusal: a grant cannot bypass the placement's `changeControl` rule.
-Remove `patch` from that grant and rerun the check; it succeeds again.
+Remove `patch` from that grant and rerun the check; it passes again.
 
 {/* Evidence: crates/registry-breg/src/change_request.rs;
     products/breg/acceptance/asset-site-placement-change-requests/registry.yaml. */}
diff --git a/docs/site/src/content/docs/tutorials/send-registry-events-to-a-webhook.mdx b/docs/site/src/content/docs/tutorials/send-registry-events-to-a-webhook.mdx
index ee5872285..6dbf573a1 100644
--- a/docs/site/src/content/docs/tutorials/send-registry-events-to-a-webhook.mdx
+++ b/docs/site/src/content/docs/tutorials/send-registry-events-to-a-webhook.mdx
@@ -5,7 +5,7 @@ status: current
 owner: registry-docs
 source_repos:
   - registry-stack
-last_reviewed: "2026-09-07"
+last_reviewed: "2026-09-08"
 doc_type: tutorial
 persona:
   - data publisher