diff --git a/workplans/GH-WP-0003-statute-v08-amendment-set.md b/workplans/GH-WP-0003-statute-v08-amendment-set.md
deleted file mode 100644
index e2257cb..0000000
--- a/workplans/GH-WP-0003-statute-v08-amendment-set.md
+++ /dev/null
@@ -1,128 +0,0 @@
----
-id: GH-WP-0003
-type: workplan
-title: "Security layer model v0.8 amendment set"
-domain: infotech
-repo: gate-house
-status: active
-owner: codex
-topic_slug: infotech
-created: "2026-09-05"
-updated: "2026-09-05"
-state_hub_workstream_id: "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.
-
-```task
-id: GH-WP-0003-T01
-status: todo
-priority: high
-```
-
-**§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.
-
-```task
-id: GH-WP-0003-T02
-status: todo
-priority: high
-```
-
-**§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.
-
-```task
-id: GH-WP-0003-T03
-status: todo
-priority: high
-```
-
-**§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.
-
-```task
-id: GH-WP-0003-T04
-status: todo
-priority: medium
-```
-
-**§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.
-
-```task
-id: GH-WP-0003-T05
-status: todo
-priority: medium
-```
-
-**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.
-
-```task
-id: GH-WP-0003-T06
-status: todo
-priority: medium
-```
-
-**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.