Owner Decision Packet — R1a/R2a Root-Cause Baseline

Date: 2026-06-18 · Workstream: Owner Decision Packet (decision bridge from the accepted R1a/R2a root-cause baseline + Codex PASS_WITH_CAVEATS → Owner decision matrix) · Revision: rev1 Class: planning / decision / scoping · READ-ONLY · NON-ENACTING · NON-AUTHORIZING · NOT remediation · NOT technical design · NOT implementation · NO blocker resolved.

0. Status and non-authorization

STATUS: PASS — this is a complete Owner-facing decision bridge built from the accepted R1a/R2a root-cause baseline and the official Codex PASS_WITH_CAVEATS review. It converts engineering root-cause truth into an Owner decision matrix; it enacts nothing.

This packet is a decision bridge only:

Accepted R1a/R2a root-cause baseline (+ Codex PASS_WITH_CAVEATS) → Owner decision (this packet's matrices) → a later, separate, Owner-gated package (design-only first, then — only if separately authorized — write-enabled).

Non-authorization (explicit). This document does not, and cannot: run any DB write / DDL / DML; restart or reload any container or service; run any worker / cron / job; trigger DOT / KG / birth / certify / promote / repair execution; backfill provenance; quarantine edges; set inspect_pen / inspect_stamp / inspect_gate; set certified=true; flip any dot_config gate; assign a governance owner; promote any agent-api contract DRY_RUN→REAL_RUN; write env / config files; patch source code; patch any source law / draft / note / prior report; create a current corpus; write technical design; implement; resolve any blocker; materialize KG / provenance / stamps / cell_id / dot_role / canonical_fields; change authority order (CONS-004); change the v0.1 baseline; promote v0.2-hardening.

Engineering/Codex PASS ≠ Owner authorization. The R1a/R2a verdicts are accepted root-cause findings, not closures. Every blocker remains OPEN. A GPT/Codex PASS on this packet is not an Owner authorization to remediate. Default disposition: HOLD.

1. Purpose

Answer, for the Owner, nine questions:

What is accepted as root-cause truth? — §3.
What caveats must constrain the wording? — §4.
Which Owner decisions are required for R1? — §5.
Which Owner decisions are required for R2? — §6.
Which package should be opened first? — §7, §8, §9.
Which items need design-only scoping before any write-enabled change? — §5, §6 (the requires write-enabled later? column).
Which items require direct write-enabled authorization? — §5, §6 (and §9).
Which actions remain forbidden? — §10.
What is the next macro after the Owner decides? — §11.

This packet keeps the decision big enough to be useful (it states both R1 and R2 matrices, the cross-package dependencies, and a recommended first move) without merging remediation, technical design, or implementation into itself.

2. Sources read

All read first-hand this run via read-only AgentData batch_read (no inference; no source unreadable).

Source	Status	Used for
`reports/r1a-kg-runner-log-provenance-source-root-cause-2026-06-18.md` (rev1)	READ (full)	R1 root-cause truth, R1 matrix, caveats CAV-1/2/5
`reports/r2a-birth-inspection-runner-cron-log-root-cause-2026-06-18.md` (rev1)	READ (full)	R2 root-cause truth, R2 matrix, caveats CAV-3/4/5
`reports/r1a-r2a-runner-cron-log-root-cause-execution-report-2026-06-18.md` (rev2/14798)	READ (full)	combined findings tally, caveat CAV-6
`reports/codex/codex-review-r1a-r2a-runner-cron-log-root-cause-2026-06-18.md` (`PASS_WITH_CAVEATS`)	READ (full)	acceptance, the 6 mandated caveats, recommended next macro
`consolidation/phase1b-runtime-truth-blocker-decision-packet-2026-06-17.md` (rev1)	READ (full)	OD-1..8 / R1–R5 macro template, CONS/CELL gates, order
`reports/r1-d39-kg-provenance-quarantine-execution-readiness-scope-2026-06-17.md` (rev1)	READ (full)	R1 prior scope, R1-OD-a/b carry
`reports/r2-birth-certify-canonical-stamp-readiness-scope-2026-06-17.md` (rev1)	READ (full)	R2 prior scope, R2-OD-a/b carry
`reports/r1-r2-parallel-readonly-scoping-execution-report-2026-06-17.md` (rev1)	READ (full)	OD-3 parallel / OD-6 verify-only baseline
`notes/dieu39-knowledge-graph-compatibility-note.md` (rev1)	READ (full)	KG goal-preserve / stage-rollout posture
`notes/dieu4-birth-process-compatibility-note.md` (rev1)	READ (full)	TEMP_ID-at-birth / canonical-at-promote mapping
`notes/dieu32-approval-owner-gate-compatibility-note.md` (rev1)	READ (full)	Owner-gate / Mức-3 quorum constraints
`notes/dieu35-dot-governance-compatibility-note.md` (rev1)	READ (full)	reuse-pattern-not-turnkey, RISK-BYPASS carry
`laws/dieu39-knowledge-graph-law.md` (v2.3, BAN HÀNH)	READ (full)	provenance-or-quarantine invariant, golden rule, §7B authority
`architecture/birth-registry-law.md` (Điều 0-G v1.0)	READ (full)	PEN→STAMP→GATE→auto-certify chain, inspector DOTs
`laws/dieu32-approval-law.md` (v1.1, BAN HÀNH)	READ (full)	quorum-by-risk, reserved/unimplemented-handler gate
`ssot/operating-rules.md` (v7.58)	READ (full)	Assembly First, read-only inventory rule, AP-CLOSE

3. Accepted root-cause truth

Accepted from the R1a/R2a reports and confirmed by the Codex PASS_WITH_CAVEATS review (each finding severity independently re-confirmed by Codex). Headline for the Owner: neither package is a broken runner. R1 is a healthy KG runner held deliberately fail-closed; R2 is a manual one-shot bootstrap that was never turned into a standing producer. Both "fixes" are net-new build/design under governance — not a restart.

3.1 R1 (KG runner / log / provenance source) — `REGISTERED_NOT_EXECUTED` by design

A KG runner exists and is healthy: incomex-agent-api-executor (agent-api-executor-local:v1, up 13 days, healthy), endpoint :8090/dispatch, bound in dot_agent_api_contract; v_dotkg_realrun_preflight.precond_endpoint_bound=GO.
KG real-run is deliberately fail-closed NO_GO: v_dotkg_realrun_preflight = REALRUN_BLOCKED_MULTI_GATE with five BLOCK gates — real_run_enabled=false, execute_enabled=false, dry_run_only=true, dotkg_owner_present=0 (governance_object_ownership empty), contract mode DRY_RUN. 0 REAL_RUN ever. This is the Điều-39 "AI ĐƯỢC ĐỀ XUẤT, KHÔNG ĐƯỢC TỰ BAN HÀNH" fail-closed posture expressed at the runtime gate — intentional gating, not a broken runner.
Only 1 of 36 KG DOTs is contracted: DOT_KG_EXPLAIN (DRY_RUN pilot, 2026-06-04). The other 35 — including both provenance DOTs (DOT_KG_PROVENANCE_TAG/AUDIT) — have no agent-api contract, no host-cron entry, no pg_cron binding.
No provenance source-of-truth in the inspected substrate: the 2199 universal_edges were created by a legacy seed LEGACY|S167H (2039 edges, 2026-03-19) + a DIRECTUS structural sync (160 edges); 0 carry provenance; the provenance-tag DOT never ran; no edge→source mapping exists. (See CAV-2 on recoverability.)
Supporting truth: pg_cron is not installed; the generic DOT/queue runtime is disabled at the master switch (process_dot_runtime.*=false, dry_run_only=true) and the queue worker has been idle since 2026-05-26; kg_quality_log=0 (downstream of never-dispatched quality DOTs); Qdrant/entity_embeddings is a vector/search store, not a provenance SoT. The config layer (kg_auto_approve_rules TBox-human / kg_source_authority 5-tier) is Điều-39-aligned and fail-closed — a readiness asset, untested because KG never executes.

3.2 R2 (birth inspection runner / cron / log) — manual one-shot bootstrap, never operationalized

The 2026-03-21 certification was a one-shot, operator-run S157-A bootstrap: dot-birth-backfill + an s157b seed run via SSH + docker exec, which stamped inspect_* + certified=true directly in the INSERT. Provenance buckets (backfill:dot-birth-backfill, backfill:s157b, SYSTEM-s157b|claude|2026-03-21) and script content agree exactly. It was not a cron job, runner job, or DB migration. (See CAV-3/CAV-4 on evidence basis.)
It never recurred because the inspect→certify producer was never operationalized: the inspector DOTs DOT-TAC-BIRTH-VERIFY (cron 0 6 * * *, metadata-only) and DOT-TAC-BIRTH-GATE are unwired registration stubs (engine_unclassified / requires_runner, no file/script, no contract, last_executed=NULL); there is no pg_cron; the host 0 6 * * * slot belongs to dot-nrm-lifecycle, not birth-verify; no host-cron/systemd entry references birth/inspect/certify; the only producers are manual CLIs nobody scheduled.
The auto-certify consumer is healthy but starved: trg_birth_auto_certify → fn_birth_auto_certify (enabled) only flips certified=true once all three inspect_* are present; with no producer it never fires for post-cutover rows. No live PG function/trigger writes inspect_pen/stamp/gate.
The backlog grows live: 1,211,557 uncertified births (0 inspect stamps; last born 2026-06-17 13:30) vs 1,402 certified (all 2026-03-21) = 0.1156%; 192 birth triggers (191 enabled) keep minting certified=false rows; event_outbox grows but is undrained and carries no birth/certify events.
GUC persisted layer empty: pg_settings WHERE name LIKE 'app.%'=0 rows and pg_db_role_setting=0 rows → the birth-gate effective mode is warning (fail-open warn) and the app.bypass_birth_gate kill-switch is not engaged by any persisted config. (See CAV-5 on the transient session layer.)

3.3 Findings tally (accepted)

13 findings (7 R1a, 6 R2a), 0 CRITICAL, no active mutation / bypass / execution observed: 7 HIGH (R1a-F1 NO_GO preflight, R1a-F2 1/36 contracted, R1a-F3 no provenance SoT; R2a-F1 no standing producer, R2a-F2 one-shot bootstrap, R2a-F3 no live inspection producer, R2a-F4 1.21M backlog), 2 MEDIUM (R1a-F4 DOT runtime disabled, R2a-F5 GUC/warn-mode), 4 INFO/LOW (R1a-F5 healthy-endpoint asset, R1a-F6 no-pg_cron/downstream, R1a-G1 executor-log gap, R2a-G1 old-log/mirror gap). Codex's findings-severity audit confirms each (R1a-F3 and R2a-F2/F5 marked PASS_WITH_CAVEAT — see §4).

4. Mandatory caveats

These constrain the wording of every claim below. They are carried exactly in substance from the R1a/R2a reports and the Codex review; they do not invalidate the baseline but they bound it.

ID	Caveat (carried exactly in substance)
CAV-1	R1a has no executor process-log proof because `docker_logs` for `incomex-agent-api-executor` was DENIED (not in allowlist). R1a is proven at the DB-contract / preflight / config layer, not the process-log layer. Wording must remain "not missing/broken at the DB-contract layer" — no claim of direct executor process-log proof.
CAV-2	R1a "no provenance source-of-truth" means no source-of-truth in the inspected substrate. It does not mean provenance can never be recovered through a future S167H / Directus source-recovery effort. Not a universal claim that no recoverable source exists outside the inspected substrate.
CAV-3	R2a "manual one-shot bootstrap" is supported by DB `dot_origin` buckets plus synced local script content, but the old 2026-03-21 container logs are unavailable (tail-only). Supported indirectly, not by old logs.
CAV-4	R2a producer scripts were read from the synced local mirror, not direct live `/opt/incomex/dot/bin` (allowlist). Do not claim byte-for-byte live-file proof — describe as synced-mirror evidence corroborated by matching DB `dot_origin`.
CAV-5	The GUC conclusion is limited to no persisted server/db/role bypass/default. The transient session state remains unreadable by the available tools. Must not claim a transient bypass certainly does not exist.
CAV-6	The combined execution report has a non-material metadata typo: the body says rev1 / content_length 14799, while AgentData metadata says rev2 / 14798 (metadata wins). Non-material unless the Owner wants a cosmetic patch.

5. R1 decision matrix

Scope: Điều 39 KG provenance / quarantine / execution readiness. Each row gives the decision, options, recommended option, reason, risk if chosen, what stays forbidden until separately authorized, and whether it requires write-enabled work. Constrained by CAV-1 / CAV-2.

R1-D1 — Keep KG read-only/dry-run, or open write-enabled R1?

Options: (a) keep read-only/dry-run; (b) open R1 design-only (decision-design scoping, no write); (c) open R1 write-enabled now.
Recommended: (b) open R1 design-only — and keep KG operationally read-only/dry-run. Do not open write-enabled R1 yet.
Reason: the runner is healthy and the five-gate NO_GO is correct fail-closed behaviour (§3.1). The right next step is to design how the gates would be cleared and where provenance would come from — not to clear them. Aligns with the Điều-39 note ("preserve goals, stage rollout") and OR Assembly First.
Risk if chosen: minimal — design-only produces paper, not runtime change. Risk of (c): clearing the fail-closed brake before a provenance SoT and a dot:kg owner exist would arm KG real-run with nothing governing it.
Forbidden until separately authorized: any gate flip, contract promotion, KG DOT execution, edge/provenance writes.
Requires write-enabled later? Yes (the eventual gate clears / build).

R1-D2 — If opening R1, which of the five gates may be cleared, and in what order?

The five gates: gate_real_run_enabled (config flip), gate_execute_enabled (config flip), gate_dry_run_only_cleared (set dry_run_only=false), gate_dotkg_owner_present (assign dot:kg owner, PROC-OWN-04), gate_contract_realrun_mode (promote DOT_KG_EXPLAIN contract DRY_RUN→REAL_RUN).
Options: clear none now (design the sequence only); or commit a clearing order now.
Recommended: clear none now. Design — not authorize — a governed order for when write-enabled R1 opens: (1) assign the dot:kg governance owner (accountability first, per Điều 37/§7B + Điều 32); (2) extend provenance/quality DOT contract coverage (R1-D4); (3) promote the contract DRY_RUN→REAL_RUN under Điều 32; (4) clear dry_run_only; (5) flip execute_enabled / real_run_enabled last, under Owner gate + verified executor health. Each clear is itself an Owner-authorized write requiring Điều 32.
Reason: owner + provenance + contract must precede the master execute switches so the fail-closed posture is removed only after something exists to govern KG writes.
Risk if chosen (the design): none (paper). Risk of clearing config flips first: removes the brake with no provenance SoT and no owner — a Điều-39 golden-rule violation.
Forbidden until separately authorized: all five gate clears.
Requires write-enabled later? Yes (every clear is a write).

R1-D3 — Assign `dot:kg` governance owner, or keep the owner gate closed?

Options: (a) keep the owner gate closed; (b) design the dot:kg owner assignment now (decide who, do not write it); (c) assign the owner now (write governance_object_ownership / PROC-OWN-04).
Recommended: (b) — decide the dot:kg owner via Điều 37 authority mapping as part of R1 design-only; keep the gate operationally closed until write-enabled R1.
Reason: governance_object_ownership=0 rows is one of the five BLOCK gates; Điều 39 §7B "Chưa đăng ký = chưa triển khai." Deciding the owner is design; writing the assignment is a governed write.
Risk if chosen: none (decision only). Risk of (c): a premature governance write arms one of the five gates ahead of the others.
Forbidden until separately authorized: writing governance_object_ownership / any owner assignment.
Requires write-enabled later? Yes (the actual assignment).

R1-D4 — Extend the agent-api contract beyond the EXPLAIN pilot to the provenance/quality DOTs?

Options: (a) keep EXPLAIN-only; (b) design the contract-coverage extension for DOT_KG_PROVENANCE_TAG/AUDIT + the quality DOTs (design-only); (c) build/wire the contracts now (write).
Recommended: (b) — design extending the agent-api-contract + dispatcher pattern (today only the EXPLAIN pilot) to the provenance/quality DOTs; design, not build. (Carries R1a-OD-3.)
Reason: 35/36 KG DOTs are unrouted; the provenance/quality machinery has no runner binding to build on until contracts are designed. Reuse the proven EXPLAIN dispatch pattern (Assembly First).
Risk if chosen: none (design). Risk of (c): wiring real-run dispatch paths before a provenance SoT and an owner exist.
Forbidden until separately authorized: promoting any contract DRY_RUN→REAL_RUN; creating contracts as a write.
Requires write-enabled later? Yes (building/wiring contracts).

R1-D5 — Choose the provenance source-of-truth path

Options: (i) DIRECTUS structural relations; (ii) LEGACY|S167H source recovery; (iii) both; (iv) defer.
Recommended: (iii) both — staged, and as an Owner-gated read-only/design study first (R1a-OD-2), not a backfill. Derive provenance for the 160 DIRECTUS edges from the Directus relation/collection definitions (structural, low controversy, derivable now in design); pursue the 2039 LEGACY|S167H edges via an Owner-controlled out-of-band seed-source recovery (the manifest is not in the substrate — CAV-2).
Reason: provenance SoT gates all KG work (Điều 39 "Không provenance = quarantine"); the two edge origins need genuinely different sources. CAV-2 keeps "no SoT in the inspected substrate" from becoming "never recoverable."
Risk if chosen: "both" is more work. DIRECTUS-only would leave ~93% of edges (2039/2199) permanently quarantine-bound under Điều 39; S167H-only stalls on a possibly-unrecoverable manifest; "defer" leaves the lone-HIGH invariant unmet.
Forbidden until separately authorized: provenance backfill / materialization; edge writes.
Requires write-enabled later? The eventual backfill Yes; the source-of-truth study is read-only/design.

R1-D6 — Should quarantine semantics be designed now?

Options: (a) design quarantine semantics now (design-only); (b) defer.
Recommended: (a) design now (paper only) — define what "quarantine" means in live runtime (e.g. a status='quarantine' lane + a fail-closed no-provenance gate honoring TBox-human/ABox-AI), sequenced with/after R1-D5. Do not build it. (Carries R1-OD-b.)
Reason: Điều 39 mandates "không provenance = quarantine," yet no built quarantine mechanism exists (only fn_preflight_guard references the word; fn_iu_kg_edge_audit only audits). Designing the semantics is decision-design appropriate to a design-only package.
Risk if chosen: low (paper); designing before the provenance-source path (R1-D5) is chosen could lock semantics prematurely — hence the sequencing note.
Forbidden until separately authorized: building/wiring quarantine; quarantining any edge.
Requires write-enabled later? No for design; Yes for any build.

R1-D7 — Can R1 proceed before CONS-002/003 + CELL gates?

Options: (a) R1 read-only/design may proceed; materialization may not; (b) block all R1 until CONS/CELL resolved.
Recommended: (a) — R1 design-only scoping may proceed now; any materialization (provenance, cell_id, dot_role, canonical_fields) must wait until CONS-002/003 + CELL-003/004/007 are resolved (Owner-gated). (Carries OD-8.)
Reason: matches Phase-1B §8 and R1a OD-8 — scoping is unblocked, materialization is not.
Risk if chosen: none for design; materializing before CONS/CELL would create canonical artifacts on an unsettled composition model.
Forbidden until separately authorized: materialization of provenance / cell_id / dot_role / canonical_fields.
Requires write-enabled later? Materialization Yes; design No.

6. R2 decision matrix

Scope: birth certify pipeline / canonical-stamp readiness. Constrained by CAV-3 / CAV-4 / CAV-5.

R2-D1 — Keep birth certify read-only, or open write-enabled R2?

Options: (a) keep read-only; (b) open R2 design-only; (c) open R2 write-enabled now.
Recommended: (b) open R2 design-only. Not write-enabled. (If resources are constrained, this is the package to open first — see §9.)
Reason: the backlog grows live (1.21M, +8 since the AM run alone) and R2 needs a standing producer that does not exist yet (§3.2). That producer must be designed before it is built; a restart is not possible because there is no standing pipeline to restart.
Risk if chosen: none (design). Risk of (c): building a producer + backfilling 1.21M rows before a channel is chosen and Đ0-G/CONS/CELL are resolved.
Forbidden until separately authorized: inspect/certify writes, producer build, backfill, restart.
Requires write-enabled later? Yes.

R2-D2 — Choose the standing producer channel

Options: (i) host cron; (ii) pg_cron; (iii) agent-api executor; (iv) job_queue worker; (v) other; (vi) defer.
Recommended: design-evaluate; do not commit a channel now. If a leaning is needed: evaluate host cron first — it is the already-proven scheduling channel on this host (the 54-entry crontab reliably runs maintenance DOTs, including dot-nrm-lifecycle at the very 0 6 slot), so wiring an inspection producer there is the lowest-net-new-infrastructure path (Assembly First) — versus the healthy-but-disabled agent-api executor (governed dispatch, but behind the master switch). pg_cron requires installing a net-new extension; the job_queue worker is disabled/idle since 2026-05-26. Defer is not recommended (backlog grows). Decide the channel at design time.
Reason: each channel has a different governance surface — host cron is operator-run (outside Điều 32), pg_cron is in-DB, the executor is governed but currently disabled. The choice determines how the producer is governed.
Risk if chosen: committing the wrong channel now locks in a producer with mismatched governance/trust.
Forbidden until separately authorized: wiring/building any producer; installing pg_cron; flipping executor master switches.
Requires write-enabled later? Yes (wiring/build).

R2-D3 — How to handle the 1,211,557 uncertified births

Options: (a) re-run a dot-inspect-pen-style inspection over the backlog; (b) re-architect a standing inspect-on-birth gate forward plus a governed one-time backlog pass; (c) certify only new births, leave the backlog uncertified; (d) defer to design.
Recommended: design (b) — a two-track approach (forward standing producer + a governed one-time backlog inspection pass) — design-only; the actual disposition is a write-enabled decision after the channel (R2-D2) and Đ0-G/CONS/CELL are resolved. Do not backfill now. (Carries R2a-OD-2.)
Reason: the backlog blocks all canonical-dependent TD; but a mass re-run of the 2026-03-21 stamp-inspect_*+certified-in-INSERT shortcut at 1.21M scale would certify without genuine inspection — exactly the un-governed pattern to avoid.
Risk if chosen: designing is safe. The risk to avoid is option (a)-as-built (mass shortcut backfill); option (c) keeps canonical TD blocked.
Forbidden until separately authorized: setting inspect_* / certified=true; re-running dot-birth-backfill / dot-inspect-pen.
Requires write-enabled later? Yes.

R2-D4 — Reuse `dot-inspect-pen` / `dot-birth-backfill` patterns, or redesign?

Options: (a) reuse the CLI scripts as-is (wire them to a runner); (b) reuse the inspection logic/pattern but redesign the producer into a governed standing runner; (c) full redesign.
Recommended: (b) — reuse the Điều 0-G PEN→STAMP→GATE→auto-certify pattern (the live consumer trg_birth_auto_certify already implements the GATE→certify half) but redesign the producer into a standing, governed runner; do not reuse the manual SSH+docker exec stamp-in-INSERT shortcut as the production path. Design-only.
Reason: mirrors the Điều 35 note ("reuse the pattern, carry the caveats — do not import the running system turnkey") and the Điều 4 note (auto-certify is the documentary ancestor of the F4 promote checker; canonical certification must pass a fail-closed checker + Owner gate / Điều 32, not async auto-certify alone). The old dot-inspect-pen only implemented Phase-A "pen"; stamp/gate were deferred to a Phase B that was never built.
Risk if chosen: reusing the backfill shortcut as production (a) re-introduces stamp-without-inspection; full redesign (c) is heavier than needed given the consumer already exists.
Forbidden until separately authorized: running the CLIs; building the producer.
Requires write-enabled later? Yes (build).

R2-D5 — Decide the BIRTH_STAMP / PROMOTE_STAMP mapping direction

Options: (a) map the F4 concepts onto the existing mechanism — BIRTH_STAMP → certified / certified_at, PROMOTE_STAMP → an end-to-end atomic birth-certify promote (evaluate reusing the fn_iu_enact atomic/fail-closed pattern), using the already-present unused canonical_address / owner / jsonb_profile columns; (b) define net-new stamp columns; (c) defer.
Recommended: (a) design the mapping onto existing fields (R2a-OD- / R2-OD-b) — design-only, gated on HOLD-2 + CONS/CELL. Do not materialize stamps.
Reason: BIRTH_STAMP/PROMOTE_STAMP are conceptual targets, not DB artifacts; the live mechanism (certified/certified_at/inspect_* + unused canonical_address/owner) already exists. Defining net-new columns alongside them would create a parallel SSOT (against Điều 39 NT11 / OR Assembly First). fn_iu_enact proves an atomic, fail-closed, post-verified promote pattern exists for the IU lineage and is a candidate to reuse for birth.
Risk if chosen: designing is safe. Option (b) risks a second SSOT; (c) keeps canonical TD blocked.
Forbidden until separately authorized: materializing BIRTH_STAMP/PROMOTE_STAMP / canonical_fields.
Requires write-enabled later? Materialization Yes; mapping design No.

R2-D6 — Decide GUC / warn→block policy

Options: (a) confirm the GUCs out-of-band + keep warn-mode; (b) confirm out-of-band + set warn→block criteria (per Điều 35 §10's AND-conditions); (c) defer.
Recommended: (b) confirm app.birth_gate_mode / app.bypass_birth_gate out-of-band (the transient session layer the tools cannot read — CAV-5) and decide the warn→block criteria — but the flip to block must wait until a standing producer exists and the Điều 35 §10 readiness criteria are met. The out-of-band confirmation itself is read-only/out-of-band, not a runtime write. (Carries R2a-OD-3; ties to Phase-1B OD-5 / R4.)
Reason: the persisted layer is confirmed empty (no bypass, warn-mode default); only the transient session value is unread (CAV-5). Flipping to block before a producer exists would hard-fail the 192 live birth triggers.
Risk if chosen: flipping to block prematurely rejects live births with no inspection path; staying warn-mode indefinitely leaves the gate fail-open.
Forbidden until separately authorized: flipping birth_gate_mode to block; any GUC write.
Requires write-enabled later? The eventual flip Yes; the out-of-band confirmation No.

R2-D7 — Can R2 proceed before Đ0-G source recovery + CONS/CELL resolution?

Options: (a) R2 read-only/design may proceed; materialization may not before Đ0-G source recovery + CONS/CELL; (b) block all R2.
Recommended: (a) — R2 design-only may proceed; any materialization (certify writes, stamps, cell_id, canonical) waits on Đ0-G source recovery + CONS-002/003 + CELL-003/004/007. (Carries OD-8.)
Reason: Đ0-G lives in architecture/ as a temporary working source (its Constitution reference law-00g-birth.md is broken); materializing canonical birth on an unrecovered source + unsettled composition model would create rework-prone artifacts.
Risk if chosen: none for design; materialization-before-recovery risks canonical rework.
Forbidden until separately authorized: materialization.
Requires write-enabled later? Materialization Yes; design No.

7. Cross-package dependencies

Question	Answer
R1 before R2?	Not required. Phase-1B's default severity order is R1→R2 (R1 is the lone HIGH finding on its own surface and the more bounded design problem).
R2 before R1?	Supported as the resource-constrained choice — R2's backlog grows live and is systemically larger, and R2 has no standing producer at all.
R1 ∥ R2 parallel?	Yes — recommended. Both are design-only with zero write footprint; the prior R1∥R2 read-only scoping already ran in parallel successfully (OD-3 parallel option).
Which decisions are independent (package-internal)?	R1-D5 (provenance SoT path), R1-D6 (quarantine semantics), R2-D2 (producer channel), R2-D3 (backlog disposition), R2-D4 (pattern reuse), R2-D5 (stamp mapping). These can be designed without cross-package coordination.
Which decisions share Owner / Điều 32 gates?	When they become write-enabled: R1-D2/D3/D4 (gate clears, owner assignment, contract promotion) and R2-D1/D2/D3/D4 (producer build, backfill) all route through Điều 32 quorum + Owner gate. R1-D3 (dot:kg owner) and R2-D2 (producer governance) both invoke Điều 37 authority mapping.
Which depend on CONS-002/003 + CELL?	R1-D7 and R2-D7 explicitly; and any materialization in either package (provenance / `cell_id` / `dot_role` / `canonical_fields` / stamps).
Which depend on source recovery?	R1-D5 (`LEGACY

Net: the two packages are safely parallelizable at the design-only tier (no shared write surface), and they converge only at two shared gates — Điều 32/37 Owner authorization (for any write-enabled clear/build) and CONS/CELL + source-recovery (for any materialization). Neither convergence is reached by a design-only package.

8. Owner options

Option	Description	Write-enabled?
A	Keep all read-only, no remediation yet.	No
B	Open R1 design-only package first.	No (design-only)
C	Open R2 design-only package first.	No (design-only)
D	Open R1 and R2 design-only in parallel.	No (design-only)
E	Authorize write-enabled remediation immediately.	Yes

Options B / C / D are design-only / decision-design scoping — they produce design-direction memos (PENDING_OWNER), not runtime change, and require a further separate Owner gate before any write. Option E is the only write-enabled option and is not recommended (see §9). Option A is the strict default-HOLD.

9. Recommended option

Recommended: Option D — open R1 and R2 design-only in parallel, as decision-design scoping, NOT write-enabled.

Why D: both root causes imply net-new governed build/design, not a restart (Codex's headline). Both packages are design-only with zero write footprint and were already run in parallel read-only without incident; designing them together loses no safety and saves a serialization round. Codex's recommended next macro is exactly this Owner Decision Packet, with write-enabled remediation, technical design, blocker resolution, and implementation all unauthorized — Option D honors that by keeping everything at the design tier behind a further Owner gate.
Resource-constrained fallback: Option C first (R2). If only one package can be opened now, open R2 first: the birth backlog keeps growing (1,211,557 and rising, +8 in a single half-day) and R2 has no standing producer at all, so a standing inspect→certify producer is the more time-sensitive design. But do not authorize writes without a separate Owner gate — opening R2 means designing the producer/channel/backlog approach, not building, restarting, or backfilling.
Why not E: write-enabled remediation now would clear fail-closed gates / build a producer / backfill 1.21M rows before the prerequisite decisions (provenance SoT path, producer channel, owner assignment, CONS/CELL, Đ0-G & S167H source recovery) are made — and Codex explicitly authorizes no write-enabled work. E is rejected.
Why not A: strict HOLD is safe but leaves the two well-bounded design questions unanswered while the backlog grows; D/C advance the design without any write.

This recommendation authorizes nothing — it is a recommendation for which design-only package(s) the Owner may choose to open. Opening any package, and any subsequent write, each require a separate Owner gate.

10. Actions still forbidden

Unchanged from the standing discipline (R1a/R2a §14, Phase-1B §11), reaffirmed here. Forbidden under this packet and under any design-only package the Owner may open (these need a separate write-enabled Owner gate):

run DB write / DDL / DML; restart or reload containers/services; run workers / cron / jobs;
trigger DOT / KG / birth / certify / promote / repair execution;
backfill provenance; quarantine edges;
set inspect_pen / inspect_stamp / inspect_gate; set certified=true;
flip any dot_config gate (incl. the five KG preflight gates, birth_gate_mode→block);
assign a governance owner; promote any agent-api contract DRY_RUN→REAL_RUN;
write env/config files; patch source code; patch any source law / draft / note / prior report;
create a current corpus; write technical design; implement; resolve any blocker;
materialize KG / provenance / stamps / cell_id / dot_role / canonical_fields;
change authority order (CONS-004); change the v0.1 baseline; promote v0.2-hardening.

Out-of-band, Owner-controlled (not performed here, not a runtime write): confirm the transient app.birth_gate_mode / app.bypass_birth_gate session value (CAV-5); recover the LEGACY|S167H seed source (R1-D5, CAV-2) and the Đ0-G source (R2-D7). The optional cosmetic patch of the combined-report metadata typo (CAV-6) is the Owner's call and is not done here.

11. Next macro recommendation

GPT reviews this Owner Decision Packet.
If accepted, Codex adversarial control review.
Owner chooses the package/design path: Option D (recommended — R1 ∥ R2 design-only), or C (R2 design-only first, resource-constrained), or B / A / E, and confirms the per-decision recommendations in §5 / §6 (or overrides them).
If a design-only package is opened: its product is a design-direction memo (PENDING_OWNER) per package — not a build. Any move from design to a write-enabled step (gate clear, owner assignment, contract promotion, producer build, backfill, stamp materialization) is a further, separate, Owner-gated workstream requiring Điều 32 quorum, and — for any materialization — CONS-002/003 + CELL-003/004/007 resolution plus the relevant source recovery.

Default disposition: HOLD. PASS = a complete decision bridge; it is not an Owner authorization to remediate. No blocker resolved; no technical design; no implementation.

12. Ready for GPT/Codex review

This packet is READY for GPT review, then Codex adversarial control review. It is a decision bridge — not remediation, not technical design, not implementation. It carries all six mandated caveats (§4), completes both decision matrices (§5, §6) and the cross-package matrix (§7), states the five Owner options (§8), and recommends one (Option D, with C as the resource-constrained fallback) without authorizing any write (§9). Every blocker remains OPEN; engineering/Codex PASS ≠ Owner authorization.

Source baseline: R1a (rev1, PASS), R2a (rev1, PASS), combined execution report (rev2/14798, PASS), Codex review (PASS_WITH_CAVEATS), Phase-1B packet (rev1, PASS) + R1/R2 scope baseline (rev1, PARTIAL ×3). Governance anchors: Điều 39 v2.3, Điều 0-G v1.0, Điều 32 v1.1, OR v7.58, and the Điều 39 / Điều 4 / Điều 32 / Điều 35 compatibility notes.