Owner Decision Matrix — Law Revision Consolidation (Workstream D0)

Status: Decision-support only. READ-ONLY · NON-ENACTING · NON-AUTHORIZING. Created: 2026-06-17 · Law Revision Workstream D0 · rev1. Companion: consolidation/law-revision-consolidation-planning-packet-2026-06-17.md (D0.1) — the full plan, 53-record matrix, mappings, caveats, blockers. Read D0.1 first. Purpose: present four clean, mutually-distinct options for what to do with the completed Law-Revision drafting work (Workstreams A / B0 / B1 / B2 / C). The Owner chooses exactly one. Nothing here is performed by D0; selecting an option is itself the authorization for the next step, after the GPT → Codex chain on D0. Standing rule: Codex/GPT/Council PASS ≠ Owner authorization. Engineering PASS ≠ Authority PASS. Default disposition: HOLD.

0. Where we are (one paragraph)

The old law corpus has been classified into 53 records (KEEP 6 · KEEP+NOTE 25 · AMEND 5 · REWRITE 1 · DEFER 16). Every AMEND record (5) and the REWRITE record (1) now has a non-enacting DRAFT in newlaws/; 8 of 25 KEEP+NOTE records have a written compatibility note; 17 KEEP+NOTE notes remain unwritten. No law has changed. No current corpus exists. No blocker is resolved. The question for the Owner is whether — and how — to move from this drafting layer toward a single consolidated reading, without enacting anything.

1. The four options at a glance

Option	One-line meaning	Builds a current corpus?	Touches `laws/`?	Resolves blockers?	Recommended?
A	Accept the planning packet as the agreed map; do not consolidate yet.	No	No	No	✅ Recommended — immediate decision on this packet
B	Authorize a future non-enacting current-corpus drafting packet (a reading/provenance layer).	No (drafts a pointer layer, not copied law text)	No	No	◻ Recommended forward step — only after Codex clears D0
C	Request fixes to specific notes / amendments / the rewrite before anything else.	No	No	No	◻ Only if review finds defects
D	Defer consolidation; open a scoped read-only Phase-1 (Batch D) to verify runtime blockers.	No	No	No (verifies, does not resolve)	◻ Recommended parallel track — the real gate to future design

The options are not all mutually exclusive in sequence: the recommended path is A now, then (after GPT→Codex on D0) B for the documentary track and D as an independent parallel track, with C invoked only if a defect is found. But the Owner selects one as the immediate decision.

2. Option A — Accept planning packet only; do not consolidate yet

What it authorizes

Acceptance of D0.1 + D0.2 as the agreed consolidation map: the agreed reading-rule for each of the 53 records, the agreed mapping of the 5 AMEND drafts / 1 REWRITE / 8 notes, the agreed list of 17 unwritten notes, the agreed source-recovery caveats, and the agreed list of blockers that stay open.
Nothing is built, copied, enacted, or resolved. The drafts stay drafts; laws/ stays untouched; the reading layer stays as-is.

What it does NOT authorize

No current corpus; no consolidation; no current-corpus drafting; no note-writing; no index re-pointing; no technical design; no Phase-1; no implementation; no blocker resolution; no laws/ edit; no enactment.

Risks

Low. Fully reversible — it only records agreement on the map. Main "risk" is no forward motion: the runtime blockers (RISK-BYPASS, HOLD-1/2, Đ39 runtime, Đ35 prod-readiness) remain unverified, and the consolidated reading remains un-assembled. Mitigated by pairing A with a later B and/or D.

Recommended next step

Send D0 through GPT → Codex. On Codex PASS, return to the Owner to choose the forward step (B and/or D). This is the disciplined, default-HOLD-consistent choice.

Required Codex / GPT control

GPT reviews D0 → Codex reviews D0. Codex PASS = "the map is usable for an Owner decision," not authorization to consolidate.

3. Option B — Authorize a non-enacting current-corpus drafting packet

What it authorizes

A future workstream (e.g., D1) to draft a single consolidated reading/provenance layer in newlaws/ — a pointer document that, per the 53-record matrix, tells a reader exactly which source to read for each law (old law as-is / old law + note / amendment draft pending Owner / rewrite draft pending Owner / defer) — plus re-pointing LAW_READING_INDEX.md at the now-existing AMEND/REWRITE drafts.
Strictly non-enacting: the layer is pointers + notes, never copied law text. laws/ stays the source of truth; the layer never becomes "the law."

What it does NOT authorize

No copying or moving of law files into any "current" location (that would create drift and is forbidden). No enactment/adoption of any draft. No technical design, Phase-1, implementation, or blocker resolution. No laws/ edit. No Constitution patch.

Risks

Medium. The central risk is mis-reading a non-enacting reading layer as an enacted "current law set." A consolidated single document looks authoritative; readers may treat the AMEND/REWRITE drafts inside it as in-force. Mitigation: every record carries its disposition + "PENDING_OWNER / DRAFT / NOT enacted" banner, and the layer is pointers-not-copies. Secondary risk: drafting it before the source-recovery decision (§9 of D0.1) means the Đ0/0-B/0-G provenance caveat must be carried prominently, not silently resolved.

Recommended next step

Choose B only after Codex clears D0 (so the map is validated first). Then scope D1 narrowly: pointer layer + index re-point, non-enacting, carrying all caveats; send D1 through GPT → Codex → Owner before it is treated as the working reading.

Required Codex / GPT control

D0 GPT → Codex first; then the D1 drafting packet itself goes GPT → Codex → Owner. Codex PASS on D1 ≠ enactment; the layer remains non-enacting until a separate (and currently out-of-scope) Owner enactment decision.

4. Option C — Request fixes to specific notes / amendments / the rewrite

What it authorizes

A targeted revision pass on one or more named artifacts (a specific note, a specific AMEND draft, or the Đ37 rewrite) to correct a defect the Owner or Codex identifies — e.g., a mis-stated preserve/retire item, a wrong old-law version label, a missing blocker, or a banner weakness.
The revised artifact stays DRAFT / NOTE / NON-ENACTING; only its content is corrected.

What it does NOT authorize

No enactment of the fixed artifact; no consolidation; no current corpus; no technical design / Phase-1 / implementation; no blocker resolution; no laws/ edit. A fix is not an adoption.

Risks

Low–Medium. Risk is mostly scope creep (a "fix" expanding into a redesign) and churn (re-reviewing artifacts that were already Codex-ready). Mitigation: name the exact artifact + exact defect; keep each fix minimal and re-run only that artifact through review.

Recommended next step

Invoke C only if D0's GPT/Codex review (or the Owner) finds a concrete defect. Otherwise skip — the artifacts are already review-ready. List the specific artifact(s) and defect(s); produce a minimal revised draft; re-review only the changed artifact.

Required Codex / GPT control

The specific revised artifact goes back through GPT → Codex. The rest of the package is unaffected. Codex PASS on the fix ≠ adoption.

5. Option D — Defer consolidation; open runtime Phase-1 blocker verification separately

What it authorizes

A scoped, read-only Phase-1 (Batch D) to verify the live-substrate blockers that sit under the entire draft edifice: RISK-BYPASS (is fn_auto_approve_add live; can the birth gate be bypassed?), HOLD-1 (iu_staging_* liveness), HOLD-2 (atomic-promote transaction), Đ39 runtime-EMPTY (KG / kg_* liveness), Đ35 production-readiness (the 14/14 health checks). Phase-1 observes and reports; it does not change governance.

What it does NOT authorize

It verifies; it does not resolve. No closing of RISK-BYPASS by code change, no schema/registry/index creation, no materialization (cell_id/dot_role/canonical_fields/KG/Species-Matrix/stamps), no technical design, no enactment, no consolidation, no laws/ edit. Even a read-only Phase-1 is separately Owner-gated and is not authorized merely by accepting D0 — choosing D is that authorization.

Risks

Medium. Live read-only queries against a production substrate carry operational caution (read-only scope must be enforced; no write, no DDL, no governance mutation). The carried operational-risk gates (RISK-GC/CAP/IDX/AP/STL/RUN/CRASH/TIME, DOT-CAP-*) bound what may be touched. Upside: D is the only option that moves the real gate — until these blockers are verified (and later resolved), no technical design or implementation can proceed regardless of how clean the documentary consolidation is.

Recommended next step

Run D as an independent parallel track to the documentary work (A→B). Define a read-only Phase-1 scope packet (which substrates, which checks, read-only enforcement), send it GPT → Codex → Owner, then execute read-only and report. Resolution of any confirmed blocker is a further Owner-gated step beyond verification.

Required Codex / GPT control

A Phase-1 scope packet goes GPT → Codex → Owner before any live read. Findings return for Owner decision. Codex PASS on the scope ≠ authorization to resolve anything — only to observe within the agreed read-only bounds.

6. Recommendation

Immediate decision: Option A — accept the planning packet as the agreed map, then send D0 through GPT → Codex. A is the conservative, fully-reversible, default-HOLD-consistent choice, and D0 itself has not yet been Codex-reviewed, so committing to a build step (B) or a live read (D) ahead of that review would run ahead of the program's own discipline.

Recommended sequence after Codex clears D0:

B (forward documentary track) — authorize a non-enacting current-corpus drafting packet (pointer layer + index re-point), carrying all source-recovery caveats; review it GPT → Codex → Owner before it becomes the working reading.
D (parallel runtime track) — open a scoped read-only Phase-1 to verify RISK-BYPASS / HOLD-1 / HOLD-2 / Đ39 runtime / Đ35 production-readiness. This is the real gate to any future technical design and should not wait on B.
C — only if review surfaces a concrete defect in a named artifact.

What no option does: none enacts a draft, none creates a current corpus by copying law text, none edits laws/, none resolves a blocker, none authorizes technical design or implementation, none changes the authority order or the v0.1-stable / FIX7 V3 baseline, and none promotes v0.2-hardening.

7. Decision record (to be completed by the Owner)

Field	Value
Option chosen (A / B / C / D)	(Owner to complete)
Date	(Owner to complete)
Conditions / scope notes	(Owner to complete — e.g., for C: which artifact + defect; for D: which substrates, read-only bounds)
GPT review of D0	(pending)
Codex review of D0	(pending)
Confirmation: no enactment, no current corpus, no `laws/` edit, no blocker resolved, v0.1 baseline unchanged	(Owner to confirm)

Ready for Codex review: YES. GPT reviews D0 → Codex reviews D0 → Owner chooses one option above.