Settle the §13 register disposition as GH-DEC-2026-006

GH-WP-0003-T03. maturity-engine holds the §13 gap register and the §13.1
stance-map inventory as queryable data and proposed the statute tables
become pointers. Two things are true at once: a statute should not carry
state, and a standard must be readable on its own.

The registers become pointers, and not before maturity-engine publishes a
committed, versioned export readable without a live query. Publication is
the migration's precondition, not its follow-up — pointing an auditor at
a live engine is not a register they can read, and would repeat in the
other direction the exact defect §13.1 was created to fix.

Until the export lands the tables stay and rows are transcribed, so
user-engine, tenant-engine, ops-warden and ops-mason are inventoried in
v0.8 either way rather than waiting on the condition.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WtJBr77gMFLrN93iEevqQJ

Assistant: claude-code
Assistant-Model: opus
Assistant-Process: 425128@bnt-lap001
Assistant-Session: f5944d8b-dac4-4e1a-87eb-8b3d8f314a63

decisions/decisions.md

@@ -570,3 +570,124 @@ single composed artifact can — most plausibly offline or forwarded verificatio
 no access to the PDP. That is a trigger for the deferred option above, not for
 returning `ActionAuthorization` to the claim endpoint, which stays forbidden on
 structural grounds regardless.
+
+## GH-DEC-2026-006 — The §13 registers become pointers only once maturity-engine publishes a readable export
+
+```yaml
+id: GH-DEC-2026-006
+kind: decision
+title: The §13 registers become pointers only once maturity-engine publishes a readable
+  export
+status: resolved
+owner: Bernd Worsch
+repo: gate-house
+standard: net-kingdom/canon/standards/security-layer-model_v0.7.md
+source_note: workplans/GH-WP-0003-statute-v08-amendment-set.md (T03)
+requested_dispositions:
+- approved
+- revised
+- rejected
+affects:
+- gate-house
+- net-kingdom
+- maturity-engine
+- ops-warden
+- ops-mason
+- user-engine
+- tenant-engine
+- access-engine
+rationale: 'A statute of record should not carry state, and §13 and §13.1 are state:
+  they change without the doctrine changing, and a hand-maintained table inside a
+  standard is a register that drifts. maturity-engine is the right holder. But a pointer
+  is only an improvement once there is something readable to point at — a standard
+  that can only be understood by querying a live engine has traded one defect for
+  a worse one, and it would make the statute unreadable to exactly the auditor it
+  exists for. The migration is therefore conditioned on a committed, versioned export
+  rather than declared outright. Until that export exists the tables stay and rows
+  are transcribed, so no repository is left without an answer while the condition
+  is outstanding.'
+decided_by: Bernd Worsch
+created: '2026-09-05T23:38:49.777532Z'
+updated: '2026-09-05T23:38:49.777532Z'
+```
+
+## Context
+
+`security-layer-model` v0.7 §13 holds the open-gap register and §13.1 the PEP
+stance-map register. Both were created because the obligations above them named a
+register that did not exist — §9.1's own logic, that a requirement whose register is
+missing is a capability catalogued without a surface. They did their job.
+
+`maturity-engine` (MAT-WP-0001) now holds both as queryable data: the §13 snapshot
+with state and owner-status intact, the §13.1 inventory, `ASM-0`…`ASM-6` registered
+as data owned by gate-house, `pep-stance-publication` owned by ops-warden, and
+blocked-clean scored equal to conforming by test. It proposes that the statute table
+become a pointer.
+
+Four repositories are waiting behind the answer. `user-engine` and `tenant-engine`
+have published stance maps and asked for §13.1 rows; ops-warden is published and
+ops-mason is not. §6.4 obliges every PEP-shaped consumer to publish and obliges those
+maps to be inventoried. Each week the question stays open, the register either
+accumulates transcription or accumulates silence.
+
+## Decision
+
+**§13 and §13.1 become pointers to `maturity-engine`, and not before it publishes a
+committed, versioned export of both registers that is readable without a live query.**
+
+Two things are true at once and the ruling holds both.
+
+**A statute should not carry state.** §13 and §13.1 change without the doctrine
+changing. A table maintained by hand inside a standard of record drifts, and every
+row transcribed into it is the manual step `maturity-engine` exists to remove. This
+is the same rule as `GH-DEC-2026-005`: the artifact is held by the layer that owns
+its data, and a repository that neither computes nor owns a fact should not be its
+register of record.
+
+**A standard must be readable on its own.** A pointer to a live engine is not a
+register an auditor can read; it is an instruction to run software. Whatever else the
+statute is, it must be legible in git, at a version, to a reader with no cluster
+access — including a reader auditing the estate precisely because they do not trust
+its running systems. Replacing a drifting table with an unreadable reference trades a
+known defect for a worse one.
+
+The condition reconciles them. `maturity-engine` computes and remembers; it also
+publishes the result as a committed artifact at a stated path and version, and the
+statute cites that path. The rows are then computed rather than transcribed, and
+still readable without a query. **Publication is the migration's precondition, not
+its follow-up.**
+
+### What happens meanwhile
+
+The tables stay, and rows continue to be transcribed into §13.1 at each version cut.
+No repository waits on the export to get an answer. `user-engine`, `tenant-engine`,
+ops-warden and ops-mason are inventoried in v0.8 whether or not the export has
+landed by then.
+
+This is deliberately the slower path. The alternative — strike the tables now and
+point at the engine — would close four open requests immediately and leave the
+statute stating an obligation whose register no reader can open, which is the exact
+defect §13.1 was created to fix. Repeating a defect in the other direction is not
+progress.
+
+### What is asked of `maturity-engine`
+
+Not a new capability, a published form of one it has. The export must be a file in
+the repository, versioned, generated rather than hand-edited, carrying the same
+fields the statute tables carry today (§13: capability, kind, declarer, owner, state,
+owner-status; §13.1: consumer, stance map path, shape), and regenerable so drift
+between the export and the engine's own state is detectable. `layer.yaml` and
+`pep-stance.yaml` are the shape to follow: published, machine-readable, and asserted
+equal to shipped behaviour by a test. §6.4 obligation 3 already requires that
+equality of every PEP; a register of those maps should not hold itself to less.
+
+When it exists, the §13 and §13.1 tables are replaced by a citation of it, and
+`maturity-engine` becomes the register of record.
+
+## Reversal
+
+Revert to tables if the export proves to drift from the engine's computed state
+faster than a hand-maintained table drifted from reality — that is, if generation and
+publication decouple. The falsifier is mechanical: a regeneration that changes the
+committed export without any underlying evidence having changed, or an underlying
+change that does not reach the export.

workplans/GH-WP-0003-statute-v08-amendment-set.md

@@ -65,7 +65,7 @@ the `GH-IN-0001` gap silently.
 
 ```task
 id: GH-WP-0003-T03
-status: todo
+status: done
 priority: high
 state_hub_task_id: "6d5efa1a-54d9-5995-bfac-d2a9f5291469"
 ```
@@ -83,9 +83,12 @@ that drifts, and that transcribing rows is exactly the manual step the engine ex
 to remove. The argument against is that a statute must be readable without a live
 query. Both are real; settle it as a decision record rather than by editing.
 
-Whichever way it goes, the outstanding rows are discharged by this task — as
-transcribed entries or as a confirmed pointer plus a check that the engine holds
-them. Do not leave the requesting repositories without an answer either way.
+Settled as `GH-DEC-2026-006`: the registers become pointers, and not before
+`maturity-engine` publishes a committed, versioned export readable without a live
+query. Publication is the precondition, not the follow-up. Until it lands the tables
+stay and rows are transcribed, so the four outstanding stance-map offers are
+inventoried in v0.8 either way — `user-engine`, `tenant-engine`, `ops-warden`
+(published) and `ops-mason` (unpublished).
 
 ```task
 id: GH-WP-0003-T04