coulomb/gate-house
4
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

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

Browse source 
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
This commit is contained in:
tegwick 2026-09-06 08:02:05 +02:00
parent e4373bafd5
commit 10a9dc71ef
2 changed files with 88 additions and 4 deletions
Download patch file Download diff file Expand all files Collapse all files

81
decisions/decisions.md
View file

@ -610,3 +610,84 @@ 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.

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

@ -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