Incomex AI Portal
KB-715F

dot-iu-cutter v0.1 — P0 Migration Sequence Plan

16 min read Revision 1
dot-iu-cutterimplementation-planningmigration-sequencep0no-executionno-ddlno-sqlrev5d

dot-iu-cutter v0.1 — P0 Migration Sequence Plan

Date: 2026-05-15 Status: IMPLEMENTATION PLANNING — Lane "sequence" Scope: PLANNING ONLY. No DDL, no SQL, no migration script, no PG mutation, no execution. Master: implementation-planning/dot-iu-cutter-v0.1-p0-implementation-planning-master-2026-05-15.md

1. Purpose

Specify the proposed per-item migration execution sequence with logical preconditions, validation checks, rollback notes, and inter-item dependency checks. The sequence carries forward the dependency graph from the migration-design master §3.

This file contains no SQL and no DDL. All steps are described at the logical level so a future execution phase can translate them into DDL/SQL.

2. Source Inputs

  • implementation-planning/dot-iu-cutter-v0.1-p0-implementation-planning-master-2026-05-15.md §5
  • implementation-planning/dot-iu-cutter-v0.1-p0-cross-cutting-resolution-plan-2026-05-15.md
  • migration-design/dot-iu-cutter-v0.1-p0-migration-design-master-2026-05-15.md §3, §4, §11
  • 6 P0 migration-design item files

3. Proposed Execution Sequence

The execution sequence matches the design dependency graph topological order:

Step 1: P0-5 decision_backlog_entry  (foundational; no upstream)
Step 2: P0-1 canonical_address       (field family on tac_logical_unit)
Step 3: P0-2 manifest_envelope + manifest_unit_block  (joint per Đ44 Step 1)
Step 4: P0-6 review_decision
Step 5: P0-3 cut_change_set + rollback_key + dot_pair_signature
Step 6: P0-4 verify_result  (joint with P0-3 per Đ44 Step 2)

Notes:

  • This is the planned execution order; it is not the only valid order. Execution-phase authoring may consolidate steps if dependency integrity is preserved.
  • Joint design pairs (P0-2 envelope+block; P0-3+P0-4 shared dot_pair_signature) execute together within a step.
  • Across steps, each successor depends on at least one predecessor table existing.

4. Per-Step Plan

4.1 Step 1 — P0-5 decision_backlog_entry

step_id: step_1
items_in_scope:
  - decision_backlog_entry
  - decision_backlog_history
  - decision_backlog_dependency
  - sweep_log
upstream_dependencies: none (foundational)
downstream_dependents_within_p0: P0-1, P0-2, P0-3, P0-4, P0-6 (all reference backlog entry FK as governance trail)

preconditions:
  - schema class created (cutter_governance per X-1)
  - Đ24 lookup tables for {kind, status, risk_class} populated per X-4 (risk_class already Đ24-ratified)
  - directus backup taken (per preflight plan)
  - dry-run environment available

validation_checks:
  - tables exist in cutter_governance schema with logical fields per P0-5 §4 design
  - FK constraint to upstream tables: none (foundational)
  - acceptance of one synthetic anti-forgetting entry in dry-run
  - markdown mirror generator scope: implementation FUTURE; mirror not part of P0 execution

rollback_planning:
  - drop newly created tables (idempotent if no successor step has run)
  - rollback strategy SAFE because no downstream P0 step depends on data in this step yet

dependency_checks_before_proceeding_to_step_2:
  - decision_backlog_entry table accepts a synthetic row
  - decision_backlog_history accepts a synthetic row
  - sweep_log accepts a synthetic row

state_at_step_end:
  - cutter_governance schema exists
  - P0-5 tables exist
  - lookup tables for P0-5 enums populated

4.2 Step 2 — P0-1 canonical_address

step_id: step_2
items_in_scope:
  - canonical_address field family on tac_logical_unit
  - canonical_address_alias table
upstream_dependencies: P0-5 (governance trail anchor for backfill audit)
downstream_dependents_within_p0: P0-2 (manifest_unit_block references canonical_address indirectly via tac_logical_unit FK)

preconditions:
  - P0-5 step complete + validated
  - Đ24 lookup table for canonical_address.authority populated (Đ0-G enum already Đ24-ratified)
  - backfill plan documented (planning-level; backfill execution is post-deploy)
  - nullable on legacy rows until backfill complete (per P0-1 §9 item 10)

validation_checks:
  - canonical_address field family exists on tac_logical_unit (nullable initially)
  - canonical_address_alias table exists in TAC or shared schema (per X-1)
  - uniqueness scope = (publication_id, canonical_address) per X-1 / X-2 / per-item Risk Review §5.5 mitigations
  - backfill dry-run on synthetic TAC rows produces expected canonical addresses
  - alias lifecycle (active / retired) round-trip on synthetic alias

rollback_planning:
  - drop canonical_address field (preserving tac_logical_unit data)
  - drop canonical_address_alias table
  - SAFE if NOT NULL constraint not yet enabled (it is NOT enabled until backfill complete; planning notes that step happens in a later sub-step)

dependency_checks_before_proceeding_to_step_3:
  - canonical_address field accepts NULL on legacy rows
  - canonical_address accepts a synthetic value
  - alias table accepts a synthetic alias

state_at_step_end:
  - tac_logical_unit has canonical_address fields (nullable)
  - canonical_address_alias table exists
  - backfill itself is NOT yet executed (separate sub-step or post-execution operational task)

4.3 Step 3 — P0-2 manifest_envelope + manifest_unit_block

step_id: step_3
items_in_scope:
  - manifest_envelope
  - manifest_unit_block
upstream_dependencies: P0-5, P0-1
downstream_dependents_within_p0: P0-6, P0-3, P0-4

preconditions:
  - Step 2 complete + validated
  - X-A ratification observed: source_span_start / source_span_end represent UTF-8 byte offsets
  - Đ24 lookup tables populated for P0-2 enums (section_type, unit_kind, body_source_policy, collision_status, risk_class, authority — all Đ24 Step 1 already ratified)
  - JSON-schema documents authored for {payload_summary, candidate_edges, report_summary} per X-3

validation_checks:
  - manifest_envelope accepts a synthetic envelope row
  - manifest_unit_block accepts synthetic unit rows with composite identity (envelope_id, unit_local_id) unique
  - source_span_start/source_span_end accept byte-offset integers
  - candidate_edges JSONB references a synthetic universal_edges row OR is empty (per Đ39 universal_edges-first)
  - decision_backlog_root_entry_id FK to decision_backlog_entry round-trip works

rollback_planning:
  - drop manifest_unit_block (FK depends on manifest_envelope)
  - drop manifest_envelope
  - SAFE if no successor step has run

dependency_checks_before_proceeding_to_step_4:
  - both manifest tables accept synthetic data
  - FK to decision_backlog_entry resolves
  - composite identity uniqueness enforced (application-layer or PG, depending on planning detail)

state_at_step_end:
  - manifest_envelope and manifest_unit_block tables exist
  - vocabulary enums in place via Đ24 lookups

4.4 Step 4 — P0-6 review_decision

step_id: step_4
items_in_scope:
  - review_decision
upstream_dependencies: P0-2, P0-5
downstream_dependents_within_p0: P0-3, P0-4

preconditions:
  - Step 3 complete + validated
  - Đ24 lookup tables populated for {verdict (PASS/FAIL/NEEDS_HUMAN), reviewer_kind (ai/human/council)} per X-4
  - reviewer-independence rule documented at application-layer enforcement boundary

validation_checks:
  - review_decision accepts a synthetic row referencing a manifest_envelope
  - verdict enum values constrained to {PASS, FAIL, NEEDS_HUMAN}
  - reviewer_identity stored as governance-seat identifier (placeholder; G-5 operational handoff)
  - escalation_ref FK to decision_backlog_entry resolves
  - prior_review_decision_id self-reference round-trip (chained re-review)
  - cross_signed_by_dot_verifier semantics documented in JSON-schema for findings

rollback_planning:
  - drop review_decision table

dependency_checks_before_proceeding_to_step_5:
  - review_decision accepts a synthetic PASS row referencing a manifest_envelope
  - reviewer independence application-layer check rejects a forbidden combination in dry-run

state_at_step_end:
  - review_decision table exists
  - independence enforcement is application-layer v0.1 (PG FUTURE)

4.5 Step 5 — P0-3 cut_change_set + rollback_key + dot_pair_signature (HIGH)

step_id: step_5
items_in_scope:
  - cut_change_set
  - cut_change_set_affected_row
  - dot_pair_signature (shared with P0-4)
upstream_dependencies: P0-2, P0-6, P0-5
downstream_dependents_within_p0: P0-4

preconditions:
  - Step 4 complete + validated
  - X-6 polish (revocation lifecycle additions) signed off by G-4 Custodian
  - DOT-pair registered via G-4 Custodian (dot-iu-cutter executor + dot-iu-cutter-verify verifier)
  - signing scheme v0.1 (hash-based) implementation present
  - dot_pair_drift / signature_failure signal routing to G-2 backlog wired
  - rollback test plan dry-run executed (per X-8) for this step's surface
  - JSON-schemas for {payload_summary, payload_envelope, before_state_snapshot, after_state_snapshot} authored per X-3

validation_checks:
  - dot_pair_signature accepts a synthetic executor_cut signature row
  - dot_pair_signature accepts a synthetic verifier_cut signature row
  - cut_change_set accepts a synthetic row with rollback_key = "RBK-<change_set_id>"
  - cut_change_set state transitions: pending → executing → committed only when both signatures valid AND tool_revision_match=true
  - cut_change_set state transition to invalid_drift on tool_revision mismatch
  - cut_change_set_affected_row accepts synthetic affected-row entries
  - exactly-one cross-reference rule on dot_pair_signature (per X-6 polish) enforced at application layer
  - rollback dry-run scripted scenarios pass per the rollback test plan

rollback_planning:
  - drop cut_change_set_affected_row first (FK to cut_change_set)
  - drop cut_change_set
  - drop dot_pair_signature LAST because verify_result (Step 6) will also reference it
  - if Step 6 has not yet run, dot_pair_signature can be dropped here; otherwise rollback must extend to Step 6 first
  - HIGH-risk: rollback never deletes change-set or affected-row entries in PRODUCTION; this rollback applies ONLY to a failed migration step

dependency_checks_before_proceeding_to_step_6:
  - synthetic CUT round-trip pass in dry-run
  - signature-failure signal routes to G-2 backlog
  - tool_revision_match=false produces invalid_drift state

state_at_step_end:
  - cut_change_set and cut_change_set_affected_row tables exist
  - dot_pair_signature table exists
  - signing scheme v0.1 active in dry-run

4.6 Step 6 — P0-4 verify_result (HIGH; joint with P0-3)

step_id: step_6
items_in_scope:
  - verify_result
  - dot_pair_signature (already exists from Step 5; only FK references added)
upstream_dependencies: P0-3, P0-2, P0-6, P0-5
downstream_dependents_within_p0: none (P0-4 is the final P0 item)

preconditions:
  - Step 5 complete + validated
  - X-7 canonicalization rule v0.1 prose ratified by Đ24 (full prose, not just placeholder)
  - canonicalization rule library scaffolding present
  - Đ24 lookup tables populated for {verify_kind, axis_1_status, axis_2_status, axis_1_drift_unit, verdict, state} per X-4
  - axis_1_drift_unit default = canonical_token per X-A
  - rollback test plan dry-run executed for verify-triggered rollback chain (per X-8)
  - DOT-pair separate execution context boundary (G-3 D4 capability intake) at the policy level — implementation may be application-layer v0.1
  - JSON-schemas authored for {findings, axis_1_drift_details, axis_2_advisory_findings} per X-3

validation_checks:
  - verify_result accepts a synthetic row referencing cut_change_set and manifest_envelope
  - axis_1_drift_unit default = canonical_token
  - canonicalization_rule_used field populated on every row
  - executor_signature_id + verifier_signature_id round-trip to dot_pair_signature
  - tool_revision_match=true required for verdict=PASS
  - disagreement between executor and verifier verdicts produces verdict=NEEDS_HUMAN
  - verdict=FAIL triggers rollback of the referenced cut_change_set in dry-run
  - prior_verify_result_id self-reference for re-VERIFY chain

rollback_planning:
  - drop verify_result table
  - dot_pair_signature retained if Step 5 retained (do not drop the shared table)
  - HIGH-risk: production rollback of verify_result rows is NEVER performed (rows are immutable); this rollback applies ONLY to migration step failure

dependency_checks_at_completion:
  - synthetic VERIFY round-trip pass in dry-run for all three verdicts (PASS, FAIL, NEEDS_HUMAN)
  - rollback chain test (verify → automatic rollback of cut_change_set) passes
  - canonicalization rule produces consistent token positions across re-runs

state_at_step_end:
  - verify_result table exists
  - axis-1 round-trip drift detection operational with canonicalization rule v0.1
  - axis-2 advisory operational
  - dual-signature criterion 28 path operational

5. Cross-Step Dependency Checks

inter_step_invariants:
  - each step's tables exist in cutter_governance OR TAC schema per X-1 placement decision
  - each step's enums are Đ24 lookup tables per X-4
  - each step's JSONB fields validate against authored JSON-schema per X-3
  - each step's FK references a populated upstream table created in an earlier step
  - canonical_address (P0-1) backfill is NOT a prerequisite for steps 3-6 because nullable on legacy rows is permitted
  - composite identity on manifest_unit_block enforces (envelope_id, unit_local_id) uniqueness per P0-2 §9 item 2

inter_step_failure_handling:
  - if any step's validation fails, do NOT proceed to the next step
  - perform rollback per that step's rollback planning
  - emit a decision_backlog_entry (kind=migration_step_failed) to record the incident (if P0-5 step is already complete)
  - escalate to Đ32 (HIGH-risk path if step 5 or 6) before retrying

idempotency_at_step_level:
  - each step's table creations must be idempotent under retry (CREATE TABLE IF NOT EXISTS pattern at execution time; planning-level note only)
  - lookup-table population must be upsert-style (planning-level note only)

6. Sequence Summary

Step P0 ID Tables Risk Rollback safety
1 P0-5 decision_backlog_entry, decision_backlog_history, decision_backlog_dependency, sweep_log Standard trivial (no downstream)
2 P0-1 canonical_address field family on tac_logical_unit, canonical_address_alias Standard safe pre-NOT-NULL
3 P0-2 manifest_envelope, manifest_unit_block Standard safe pre-Step-4
4 P0-6 review_decision Standard safe pre-Step-5
5 P0-3 cut_change_set, cut_change_set_affected_row, dot_pair_signature HIGH safe pre-Step-6; HIGH attention
6 P0-4 verify_result HIGH dot_pair_signature shared with Step 5; rollback chain test plan required

7. What This Plan Does NOT Do

this_file_does_NOT:
  - write any SQL or DDL
  - generate any migration script
  - execute any migration
  - mutate PG / Qdrant / Directus
  - populate any lookup table
  - run any backfill
  - generate any DOT-pair signature
  - run any rollback or verify
  - cause any side effect outside this markdown file

8. Explicit Confirmation

no_ddl_written: true
no_sql_written: true
no_create_table_or_alter_table_in_this_document: true
no_column_ddl_in_this_document: true
no_index_ddl: true
no_constraint_ddl: true
no_trigger_function_or_rls_policy: true
no_migration_script_written: true
no_migration_executed: true
no_pg_mutation: true
no_qdrant_mutation: true
no_directus_mutation: true
no_data_writes: true
no_implementation_execution: true
no_phase_prior_file_modified: true
output_form: migration_sequence_planning_only
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/implementation-planning/dot-iu-cutter-v0.1-p0-migration-sequence-plan-2026-05-15.md