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

id	type	title	domain	repo	status	owner	topic_slug	created	updated	state_hub_workstream_id
GH-WP-0003	workplan	Security layer model v0.8 amendment set	infotech	gate-house	active	codex	infotech	2026-09-05	2026-09-05	a331dc88-c9bc-5d2a-9ff1-2aa7e837c3bb

Security layer model v0.8 amendment set

Goal

Land the queued amendments to security-layer-model as v0.8: the §9.7.3 consume-ordering protocol clarification, the §11 emission-guarantee declaration check, the §13/§13.1 register disposition against maturity-engine, the §9.5 posture/maturity recomputability boundary, and the GH-DEC-2026-005 split-validation doctrine. Each is currently doctrine held in a gate-house contract or decision rather than in the accepted statute.

Why now

security-layer-model_v0.7.md is accepted and must not be patched in place. Since its acceptance, five separate rulings have been made that belong in the statute and are currently held in gate-house contracts, decision records, or a reply in another repository's inbox. Each was correctly kept out of v0.7; together they are now a version.

The risk of leaving them scattered is not that any one is wrong — each was argued where it was made. It is that a reader of the accepted statute gets an answer that the estate no longer holds, and that the register sections (§13, §13.1) are accumulating rows in a document that four repositories have said should be a pointer.

Gate House authors the amendment set. net-kingdom publishes. Nothing here edits v0.7.

id: GH-WP-0003-T01
status: todo
priority: high
state_hub_task_id: "330d9739-f172-536d-82f6-74eec03902e0"

§9.7.3 — consume ordering. v0.7 reads as if the protected action must precede the consume call. GH-DEC-2026-003 and docs/contracts/approval-consumption.md establish the opposite: the PEP MUST obtain a successful consume before the side effect, because act-then-consume lets CAS prevent only the second record and not the second side effect. Carry the clarification into §9.7.3 without retracting the forensic claim that consumption MUST NOT be inferred from a decision record.

id: GH-WP-0003-T02
status: todo
priority: high
state_hub_task_id: "fe278b70-8c05-539c-9f41-4019c3c35520"

§11 — emission-guarantee declaration check. Add the conformance check drafted as the last section of docs/contracts/approval-emission-detection.md: a load-bearing evidence source declares a local outbox plus heartbeat-or-reconciliation; an attributive non-atomic source declares the trade and does not claim completeness. This exists so the next engine catalogued as an evidence source cannot reintroduce the GH-IN-0001 gap silently.

id: GH-WP-0003-T03
status: todo
priority: high
state_hub_task_id: "6d5efa1a-54d9-5995-bfac-d2a9f5291469"

§13 and §13.1 — register disposition. maturity-engine (MAT-WP-0001) holds the §13 gap-register snapshot and the §13.1 stance-map inventory as queryable data, with ASM-0…ASM-6 registered as data owned by gate-house and pep-stance-publication owned by ops-warden. Four repositories have offered §13.1 rows — user-engine/pep-stance.yaml, tenant-engine/pep-stance.yaml, ops-warden published, ops-mason unpublished.

Decide whether §13 becomes a pointer to maturity-engine or stays a table. The argument for the pointer is that a hand-maintained table in a statute is a register that drifts, and that transcribing rows is exactly the manual step the engine exists 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.

id: GH-WP-0003-T04
status: todo
priority: medium
state_hub_task_id: "89ffd56e-5abf-5003-889e-1d00c3453b23"

§9.5 — the posture/maturity boundary. kings-guard (KG-DEC-2026-002, kings-guard/docs/PostureMaturityBoundary.md) argues that the discriminator is recomputability, not volatility: given the same criteria and the same evidence, if you MUST get the same answer it is maturity and belongs in an engine; if you CANNOT promise the same answer it is posture and belongs in Staff. The argument is that volatility describes the two things without partitioning them, and every case it does not obviously cover becomes an argument at exactly the boundary §6 says must not be open to argument.

Assess and dispose. If adopted, it carries a constraint kings-guard has already accepted — capability readiness MUST NOT be an input to posture — and an honest limit: "the same evidence" is not yet well defined estate-wide, which makes §17 load-bearing for the test.

id: GH-WP-0003-T05
status: todo
priority: medium
state_hub_task_id: "087d3f67-66ef-59a3-8d4b-26ebfa5b2d00"

Split validation as statute. GH-DEC-2026-005 states that a PEP validates each artifact against the layer that owns its data and that a PIP MUST NOT republish the PDP's decision. That is a general property of the layer model, not a fact about the approval path, and it currently lives only in a decision record and a contract. Place it in the statute where §8's three-way split is stated.

id: GH-WP-0003-T06
status: todo
priority: medium
state_hub_task_id: "ecc01a7b-22df-5a9c-a29b-eb7559713ca7"

Assemble, circulate, publish. Cut security-layer-model_v0.8.md, circulate for assent as v0.6 and v0.7 were, and hand to net-kingdom for publication. Record dispositions of the returned findings. v0.7 stays accepted and unedited until v0.8 is accepted in its place.