diff --git a/decisions/decisions.md b/decisions/decisions.md index 4edbf83..799f9c0 100644 --- a/decisions/decisions.md +++ b/decisions/decisions.md @@ -570,124 +570,3 @@ 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. diff --git a/workplans/GH-WP-0003-statute-v08-amendment-set.md b/workplans/GH-WP-0003-statute-v08-amendment-set.md index 0e1a635..da21d8a 100644 --- a/workplans/GH-WP-0003-statute-v08-amendment-set.md +++ b/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: done +status: todo priority: high state_hub_task_id: "6d5efa1a-54d9-5995-bfac-d2a9f5291469" ``` @@ -83,12 +83,9 @@ 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. -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). +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. ```task id: GH-WP-0003-T04