dot-iu-cutter v0.2 — P0-2 BR-6 Invariant Integration

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.2-design/dot-iu-cutter-v0.2-p0-2-br-6-invariant-integration-2026-05-16.md
revision: r1
date: 2026-05-16
author: Agent (Claude Code CLI, Opus 4.7 1M)
phase: v0.2 — P0-2 manifest DESIGN (LOGICAL ONLY)
no_ddl_written: TRUE

Maps the six BR-6 binding invariants (GPT BR-6 absorption review, 2026-05-16) into the P0-2 manifest design: what each invariant requires the design to encode now, what is deferred to P1, and what the design review must verify.

---

§1 — Invariant → Design Mapping

INV-1 — canonical_address immutable; split/merge coins new addresses; alias trail mandatory

• Encoded now: no manifest column ever writes public.tac_logical_unit.canonical_address. origin blocks carry NULL proposed_canonical_address (predecessor keeps its live canonical); result blocks carry the proposed new address only.
• Deferred to P1: the executor coins the address (per GOV-1) and emits the alias trail.
• Review must verify: there is no path in the design by which the manifest mutates a live canonical; proposed_canonical_address is clearly proposal-only.

INV-2 — successor cannot gain higher authority without explicit re-enactment

• Encoded now: proposed_authority is a snapshot field, not an authority-grant mechanism. No manifest column elevates live tac_logical_unit.authority.
• Deferred to P1 / GOV-2: the actual inheritance/escalation rule (GOV-2, unresolved) and its enforcement.
• Review must verify: proposed_authority cannot, by design, write back to the live authority column; escalation requires the review gate (INV-5) + re-enactment path.

INV-3 — successors inherit canonical_address_format_version; no downgrade

• Encoded now: canonical_address_format_version is not a writable manifest column — modelled as an inheritance relation only (unit-block design §8).
• Deferred to P1: any format-version evolution is a separate governed path.
• Review must verify: the design exposes no field that could record a downgraded format version on a successor.

INV-4 — topology change emits alias rows at P1 enactment

• Encoded now: the manifest records enough to derive alias rows (origin's live canonical via target_unit_id, result's proposed_canonical_address, operation_kind, block_role) without any manifest↔alias coupling.
• Deferred to P1: the actual alias-row emission (alias table stays empty).
• Review must verify: there is no manifest→canonical_address_alias FK/column; the derivation inputs are all present.

INV-5 — split/merge is review-gated

• Encoded now: manifest_envelope.escalation_ref (soft → decision_backlog_entry)
  • the status lifecycle whose only under_review → accepted path is via a review decision. The manifest cannot self-accept.
• Deferred to P0-6/P1: review_decision itself (dependency note only).
• Review must verify: no status transition in the design bypasses the review hook.

INV-6 — metadata mutation flows through cut_change_set + verify_result only

• Encoded now: manifest_envelope.cut_change_set_ref (soft) names the change-set; the manifest performs no mutation and stores no execution-state.
• Deferred to P1: actual cut_change_set application + verify_result proof.
• Review must verify: the manifest has no column that records or performs an out-of-band metadata mutation (no "applied"/"edges_written" flags).

§2 — What Must Be Encoded Now (P0-2)

encoded_now:
  - operation_kind {first_cut,split,merge}            (BR-6 discriminator)
  - block_role {origin,result}                        (pre/post-image; INV-1/2/4)
  - source_span mandatory                             (span algebra representable)
  - proposed_canonical_address / proposed_authority   (proposal-only; INV-1/2)
  - escalation_ref soft                               (INV-5 gate hook)
  - cut_change_set_ref soft                           (INV-6 change-set naming)
  - candidate_edges JSONB                             (edge-redistribution INTENT)
  - render_order column                               (ordering carried)
  - soft uuid refs only + single in-schema FK         (decoupled, additive)

§3 — What Is Deferred to P1

deferred_to_P1:
  - address coining + alias-row emission (INV-1/INV-4)
  - authority inheritance enforcement (INV-2; rule = GOV-2)
  - format-version evolution path (INV-3)
  - review_decision table + actual review (INV-5; P0-6)
  - cut_change_set application + verify_result proof (INV-6)
  - edge redistribution executor, birth/lifecycle writes, hierarchy re-parenting,
    render_order recompute
  - span partition/coverage validation (application-layer/dry-run at P1)

§4 — What the Design Review Must Verify

review_checklist:
  - no manifest column mutates a live SSOT (canonical_address / authority / format_version)
  - no manifest↔canonical_address_alias coupling exists
  - escalation gate cannot be bypassed by any status transition
  - no out-of-band mutation/execution-state column on the manifest
  - all cross-schema refs are soft uuid; only one in-schema FK (block→envelope)
  - JSONB fields carry INTENT only; no edge tables introduced
  - GOV-1/2/3-dependent columns are present but their SEMANTICS remain open
    (consistent with DDL-freeze gate)

§5 — How P0-2 Avoids Overbuilding Split/Merge Execution

• Manifest = proposal/grouping layer only; executor = P1. No execution-state, no triggers, no edge tables, no alias writers, no lifecycle/birth writers.
• Edge/report concerns captured as JSONB intent, not relational machinery.
• Tables created empty; rollback = DROP TABLE (v0.1 precedent).
• The forward-compat test: P1 must be able to enact a split/merge without any P0-2 schema change — satisfied by operation_kind + block_role + source_span + soft refs + candidate_edges. Anything beyond that is deliberately not built here.

§6 — Hard Boundaries

no_DDL_written: TRUE
no_split_merge_execution_designed: TRUE
no_alias_coupling: TRUE
GOV_self_closed: FALSE
output_form: p0_2_br_6_invariant_integration

End of BR-6 invariant integration.