USER: Good timing — that's exactly the corridor L1B-CAP-01 §4 opened. Worth flagging up front though: this is a different category of instrument than anything drafted so far in this thread. L1B-ROADMAP-01 was read-only reconnaissance and L1B-CAP-01 was pure ratification — neither touched the repository. This one, if adjudicated, actually authorizes Codex to mutate corpus_threads schema state and assign canonical IDs. That's real execution risk, so I've structured it to gate itself rather than hand over a blank check, and it's still a draft on my end — same role separation as before, I propose and draft, you adjudicate, Thunk reviews before or alongside.
The gating logic: the roadmap left genuine ambiguity in play — whether content/provenance columns are actually absent from live corpus_threads or just inconsistently populated across scripts is an empirical question nobody's queried live yet, and same for whether the 144 missing IDs have any collision risk against the 29 extras also on record. Committing to "resolve and mutate" in one uninterrupted motion risks exactly the kind of irreversible move this project has been careful to avoid elsewhere. So I split it into a diagnostic phase and a resolution phase, with the second only auto-proceeding if the first comes back clean.
```
PAC L1B-EXEC-01 — EXECUTION AUTHORIZATION
Schema/Content/Provenance Contract Resolution + Canonical ID Mapping
Prepared by: Claude, at David's direction, under PAC L1B-CAP-01 §4
Status: DRAFT — pending Thunk peer review and David adjudication
Executes steps 1-3 of the PAC L1B-CAP-01 §3 assessment framework —
Layer 1B source/ID confirmation, corpus_threads schema/content/
provenance contract resolution, and artifact shape normalization —
under the parallel-work authorization established at L1B-CAP-01 §4.
This PAC does not execute step 4 (ingestion) or any step beyond it.
- Confirm the Layer 1B source-of-truth input set against live
repository and (if accessible) live Supabase state.
- Resolve canonical ID mapping for the 144 Layer 1B missing IDs,
including collision/gap semantics against the 29 extra IDs on
record in ingest_diff_layer1b.json.
- Resolve the corpus_threads content/provenance contract: determine
whether the columns hydrate_corpus_threads.py expects are actually
absent from the live table (per ingest_local_artifacts.py's report)
or present-but-inconsistently-populated, and reconcile the two
scripts to a single contract.
- Normalize local artifact shape to match the resolved contract.
NOT authorized under this PAC: Layer 1B ingestion itself (step 4),
count/provenance/field verification (step 5), classification or
field assignment (step 6), relation regeneration (step 7), crawler/
publication rebuild (step 8), lineage work (step 9), or Domain 8/
PAC H-C reassessment (step 10). This PAC terminates at "ready to
ingest," not "ingested." Ingestion requires its own separate PAC per
L1B-ROADMAP-01 §1 and L1B-CAP-01 §3, step 4.
═══════════════════════════════
4. PHASE STRUCTURE AND GATING
═══════════════════════════════
PHASE 1 — DIAGNOSTIC (read-only, authorized immediately on
adjudication):
- Query live corpus_threads schema directly to confirm actual
presence/absence of content and provenance columns, resolving the
ingest_local_artifacts.py vs hydrate_corpus_threads.py discrepancy
against ground truth rather than against either script's assumption.
- Determine collision/gap semantics for the 144 missing IDs against
existing corpus_threads rows and the 29 extra IDs.
- Capture a pre-mutation snapshot (row counts by ID prefix, field_id
distribution, null counts) sufficient for rollback comparison.
- Produce a findings report labeled source-tier / synthetic /
not-found per this project's standing evidentiary discipline.
GATE: Phase 2 proceeds automatically only if Phase 1 findings show
(a) no ID collisions requiring judgment, and (b) a schema resolution
path that is purely additive (e.g., adding absent columns) rather
than destructive or ambiguous between multiple valid contracts. If
either condition fails, execution halts after Phase 1 and returns to
adjudication with the findings report attached, rather than proceeding
on Codex's own judgment.
PHASE 2 — RESOLUTION (execution, conditional per gate above):
- Apply the additive schema resolution and/or script contract fix.
- Assign canonical IDs per the resolved mapping.
- Normalize artifact shape accordingly.
- No destructive schema operation (column drop/rename/type change on
existing populated columns) is authorized under this PAC regardless
of gate outcome; any such need halts and returns to adjudication.
The Phase 1 pre-mutation snapshot is mandatory before any Phase 2
write occurs. Post-mutation, Codex reports matching post-state counts
against that snapshot. No mutation proceeds without both snapshots
existing in the execution report.
Final execution report must label every claim source-tier, synthetic
articulation, or not-found, per standing project discipline. It must
state explicitly whether Phase 2 executed, halted at the gate, or was
skipped, and why. No result may be characterized as "ingestion-ready"
beyond what Phase 1/2 actually verified.
- INV-2: corpus-provenance must not be implied complete by schema
presence alone; content population remains a separate, later
concern outside this PAC's scope.
- INV-3: ID assignment under Phase 2 is mechanical resolution of an
already-identified gap, not a new identity declaration — R-IDENTITY-
DECL-01 (still open per cycle-1-closure.md) is not resolved by this
PAC and is not touched by it.
- INV-5: no probe surface, report function, or error boundary may be
altered under this authorization.
- INV-6: no relation or topology work occurs under this PAC; nothing
here privileges access frequency or ordering.
═══════════════════════════════
8. RELATIONSHIP TO PAC L1B-CAP-01
═══════════════════════════════
This PAC executes under the parallel-work boundary at L1B-CAP-01 §4
and does not require L1B-CAP-01 to be re-adjudicated. It does not
modify the §3 assessment framework. Completion of this PAC (Phase 1
and Phase 2, whatever the outcome) is what activates L1B-CAP-01 §5's
one-time review trigger — that review has not yet been triggered and
does not gate the start of this PAC.
═══════════════════════════════
9. CONSTITUTIONAL STATUS DECLARATION
═══════════════════════════════
ACTIVE CORRIDOR: MI 6.0.x — Layer 1B, execution track
ACTIVE CYCLE: N/A to this directive — parallel to QCEP-1.1 Cycle 1
EXECUTION STATUS: DRAFT — PENDING THUNK REVIEW AND DAVID ADJUDICATION
AUTHORIZED OBJECTIVE (upon adjudication): resolve schema/content/
provenance contract and canonical ID mapping per gated two-phase
structure above; no ingestion or downstream step authorized
FILES MUTATED: none (drafting stage)
HALT CONDITIONS:
- Phase 1 finds ID collision requiring judgment
- Phase 1 finds schema resolution is destructive or ambiguous
- pre-mutation snapshot cannot be captured
DRIFT DETECTED: none
OBSERVABILITY STATUS: preserved
NEXT CONSTITUTIONAL STATE:
- upon this PAC's completion (any outcome), L1B-CAP-01 §5 review
trigger activates
- ingestion (L1B-CAP-01 §3, step 4) remains unauthorized pending a
separate future PAC
═══════════════════════════════
```
That's ready for Thunk's pass and your adjudication whenever you're back — no rush on it.
ASSISTANT: My review is favorable overall. This is materially stronger than an unconditional execution directive because it constrains the executor to evidence-driven progression and explicitly limits authority. I do, however, see several places where the authorization boundary can be tightened.
### What is working well
The two-phase structure is the right approach.
The most important improvement over earlier drafts is that Phase 2 is no longer assumed. Instead it is contingent on empirical findings. That aligns with the project's general pattern of:
> observe → characterize → adjudicate → mutate
rather than
> infer → mutate.
Likewise, the explicit exclusions are clean. There is very little opportunity for an executor to "helpfully" wander into downstream Layer 1B work.
The rollback requirements are also appropriate. Requiring a pre-mutation snapshot before any write is exactly the sort of mechanical safeguard that belongs in an execution PAC.
---
## Items I would tighten
### 1. "Resolve canonical ID mapping" is still too broad.
Instead, authorize only the specific operations intended.
For example:
> Determine the canonical mapping required for the 144 Layer 1B missing IDs. Apply that mapping only if it consists solely of assigning previously unassigned canonical IDs without modifying any existing canonical identifier.
That removes a surprising amount of discretion.
---
### 2. Define "purely additive"
The gate currently says:
> purely additive
but doesn't define it.
I'd explicitly enumerate.
Something like:
> Purely additive means operations limited to:
>
> * ADD COLUMN
> * populating previously NULL values
> * creation of indexes
> * creation of constraints that do not invalidate existing rows
> * updates to previously unassigned canonical IDs
>
> It excludes:
>
> * DROP COLUMN
> * ALTER COLUMN TYPE
> * RENAME COLUMN
> * deletion of rows
> * reassignment of existing canonical IDs
> * destructive data migration
Now Codex has almost no room to reinterpret "additive."
---
### 3. Require evidence before every conclusion
Phase 1 currently says
> determine collision semantics
I'd strengthen that to something closer to
> Every determination must cite the repository artifact, database observation, or execution output from which it was derived.
That fits your project's evidentiary discipline.
---
### 4. Separate "script contract" from "database contract"
This is subtle.
Currently:
> reconcile the two scripts to a single contract
could mean
> modify both scripts
or
> modify the database
or both.
Those are different operations.
I would instead state:
> First determine the canonical database contract.
>
> Then modify only those scripts necessary to conform to that contract.
That establishes directionality.
Database truth first.
Scripts second.
---
### 5. Tighten the automatic gate
Right now the gate is binary.
I would add one additional automatic halt.
Something like:
> Phase 2 shall not execute if Phase 1 reveals multiple equally-valid implementation paths.
That prevents Codex from becoming an architect.
---
### 6. Require an execution diff
After Phase 2 I would require something like
> Report every file modified, every schema object modified, every SQL statement executed, and every row count changed.
That makes later archaeology dramatically easier.
---
## Minor wording changes
I would replace
> Resolve canonical ID mapping
with
> Verify and, if authorized by the Phase 1 gate, apply the canonical ID mapping.
---
I would replace
> Normalize local artifact shape
with
> Normalize local artifact structure to the resolved canonical contract.
"Shape" is understandable, but "structure" is more precise.
---
I would replace
> schema/content/provenance contract
with
> corpus_threads schema contract together with its content/provenance population contract.
Those are actually two contracts.
---
## One constitutional observation
This PAC crosses a boundary that your previous documents did not.
Everything before this was primarily epistemic:
> What is true?
This document becomes operational:
> Make reality conform to the verified model.
That transition is significant enough that I would preserve this PAC as its own repository artifact once ratified. It is not merely another planning note; it is the first authorization in the Layer 1B corridor that conditionally permits mutation of the repository and database. From an archaeological standpoint, it marks the point where the project moves from reconnaissance into controlled execution.
## Verdict
I would rate this **approximately 9.5/10** as an execution authorization.
I would recommend **ratification after incorporating the tightening points above**, particularly:
1. Narrow "canonical ID mapping" authority.
2. Formally define "purely additive."
3. Establish the database contract as authoritative before script modifications.
4. Add a halt condition when multiple valid implementation paths exist.
5. Require a complete execution diff in the final report.
With those adjustments, the directive becomes highly constrained, mechanically auditable, and leaves very little room for executor interpretation beyond what has been explicitly authorized.