dot-iu-cutter v0.1 — P0 Cross-Cutting Decision Register

Date: 2026-05-15 Status: Đ32 P0 RISK REVIEW — Cross-Cutting Decision Register Scope: RISK REVIEW ONLY. No DDL, no SQL, no migration, no PG mutation, no implementation planning, no implementation execution. Master: risk-review/dot-iu-cutter-v0.1-dieu32-p0-risk-review-master-2026-05-15.md

---

1. Purpose

Per GPT §3.2 of the migration-design-package review, the Đ32 P0 Risk Review phase MUST create a dedicated cross-cutting decision register rather than leave the open decisions distributed across per-item documents. This file lists the 8 prioritized cross-cutting decisions, classifies each by gate (must-resolve-before-planning vs must-resolve-before-execution), and records the recommendation already surfaced in the migration-design risk/coverage report and the per-item designs.

Cross-cutting decisions are logical — no SQL, no DDL, no signing-scheme primitives, no canonicalization-rule prose.

2. Decision Identification

8 cross-cutting decisions are tracked. The ID column uses the X-… prefix to distinguish cross-cutting from per-item decisions.

ID	Decision title	Source
X-A	source_span unit ↔ axis_1_drift_unit alignment	P0-2 §9 item 4; P0-4 §6; GPT §3.2 #1
X-1	Schema placement for new objects	risk/coverage §5.1 X-1; GPT §3.2 #2
X-2	Primary ID form (uuid vs bigserial vs deterministic)	risk/coverage §5.1 X-2; GPT §3.2 #3
X-3	JSONB validation policy	risk/coverage §5.1 X-3; GPT §3.2 #4
X-4	Enum implementation strategy	risk/coverage §5.1 X-4; GPT §3.2 #5
X-6	dot_pair_signature shape	P0-3 §4.3; P0-4 §4.1; GPT §3.2 #6
X-7	Canonicalization rule v0.1	P0-4 §6 + §12 item 2; GPT §3.2 #7
X-8	Rollback test plan requirement	P0-3 §12; P0-4 §15; GPT §3.2 #8

Ordering note: X-A is the highest-priority design-level decision (joint P0-2/P0-4) and is the only design-level blocker to opening implementation planning.

---

3. Decision Detail

3.1 X-A — source_span unit ↔ axis_1_drift_unit alignment

id: X-A
title: source_span unit on manifest_unit_block (P0-2) ↔ axis_1_drift_unit on verify_result (P0-4) MUST align
affected_p0_items: [P0-2, P0-4]
options:
  option_1:
    name: byte_for_both
    description: source_span = byte offsets; drift_unit = byte
    pros: maximally precise; deterministic
    cons: trivial encoding differences inflate drift; not the cutter's typical unit
  option_2:
    name: line_for_both
    description: source_span = line ranges; drift_unit = line
    pros: human-readable
    cons: misses sub-line drift; CRLF normalization needed
  option_3:
    name: canonical_token_for_both
    description: source_span = canonical_token positions; drift_unit = canonical_token
    pros: handles whitespace/CRLF; semantic alignment
    cons: requires canonicalization rule per source_kind (X-7); span↔file offset conversion needed for editor tooling
  option_4_recommended:
    name: byte_span_canonical_token_drift_with_conversion
    description: source_span = byte offsets (precise span); axis_1_drift_unit = canonical_token; canonicalization rule maps byte spans → canonical_token positions during drift calculation
    pros: precise span retention + semantic comparison; matches P0-4 §6 recommendation
    cons: depends on X-7 canonicalization rule v0.1; conversion logic must be deterministic
recommendation: option_4 (byte source_span + canonical_token drift with conversion)
risk_if_unresolved: HIGH — systematic VERIFY failure if MARK-span and VERIFY-drift use different unit semantics
owner: Đ24 vocabulary owner + Đ44 family ratifier (joint); Đ32 reviews
must_resolve_before_implementation_planning: TRUE
must_resolve_before_implementation_execution: TRUE
gate_classification: design-level blocker
dependent_on: X-7 (canonicalization rule v0.1)

3.2 X-1 — Schema placement for new objects

id: X-1
title: schema placement for new P0 objects (TAC vs new schema class)
affected_p0_items: [P0-2, P0-3, P0-4, P0-5, P0-6]
options:
  option_1:
    name: existing_TAC_schema
    description: place all new tables in existing TAC schema (alongside tac_logical_unit etc.)
    pros: zero new schema; simpler permission model
    cons: dilutes TAC schema semantics; manifest/cut/verify/review/backlog are governance, not TAC content
  option_2_recommended:
    name: new_schema_class_for_governance_and_manifest_family
    description: new schema class for governance/manifest family; TAC stays content-only
    pros: clean separation of concerns; supports Đ44 family registry pattern; matches risk/coverage §5.1 X-1 recommendation
    cons: requires new schema creation; permission/role mapping per Đ33/Đ43 confirmation
  option_3:
    name: split_governance_vs_manifest_into_two_schemas
    description: manifest_* in one schema; cut/verify/review/backlog in another
    pros: even finer separation
    cons: complicates joins across governance + manifest; not justified at P0
recommendation: option_2 (new schema class for governance/manifest family)
risk_if_unresolved: medium — affects all FK references and DDL form
owner: Đ44 family registry custodian + Đ33/Đ43 schema authority
must_resolve_before_implementation_planning: FALSE (decision can be made during planning)
must_resolve_before_implementation_execution: TRUE
gate_classification: planning-level

3.3 X-2 — Primary ID form

id: X-2
title: primary ID form for new objects (uuid vs bigserial vs deterministic text)
affected_p0_items: [P0-2, P0-3, P0-4, P0-5, P0-6]
options:
  option_1_recommended:
    name: uuid_with_human_aliases
    description: uuid primary key for global uniqueness; human-readable aliases where useful (e.g., decision_id_human in P0-5, rollback_key in P0-3 = "RBK-<uuid>")
    pros: global uniqueness; safe across replication/sharding; matches risk/coverage §5.1 X-2 recommendation
    cons: larger storage; less human-readable on its own
  option_2:
    name: bigserial
    description: bigserial primary key
    pros: smaller; sequential
    cons: not safe across replication/sharding; cross-environment migration risk
  option_3:
    name: deterministic_text_only
    description: human-readable deterministic IDs everywhere
    pros: maximally human-readable
    cons: collision risk; uniqueness enforcement complexity
recommendation: option_1 (uuid + human aliases on user-facing fields)
risk_if_unresolved: medium — affects FK definitions and ID generation logic
owner: Đ44 family registry custodian
must_resolve_before_implementation_planning: FALSE
must_resolve_before_implementation_execution: TRUE
gate_classification: planning-level

3.4 X-3 — JSONB validation policy

id: X-3
title: JSONB validation policy across all P0 items
affected_p0_items: [P0-2 (payload_summary, candidate_edges, report_summary), P0-3 (payload_envelope, payload_summary, before/after snapshots), P0-4 (findings, axis_1_drift_details, axis_2_advisory_findings), P0-5 (closure_evidence), P0-6 (findings)]
options:
  option_1_recommended:
    name: application_layer_v0_1_then_pg_jsonb_check_FUTURE
    description: application-layer validation v0.1; PG jsonb_check FUTURE
    pros: low implementation cost v0.1; matches risk/coverage §5.1 X-3 recommendation; aligns with Đ44 A.6 #3 JSONB acceptance
    cons: bypass risk if application validation is incomplete
  option_2:
    name: pg_jsonb_check_immediately
    description: PG jsonb_check constraints from v0.1
    pros: strongest enforcement
    cons: complex JSON-schema-in-PG; higher v0.1 implementation cost; may slow first migration
  option_3:
    name: no_validation_strict_freeform
    description: accept any JSONB content
    pros: maximum flexibility
    cons: vocabulary discipline degrades; conflicts with Đ24
recommendation: option_1 (application-layer v0.1; PG jsonb_check FUTURE)
risk_if_unresolved: medium — affects every JSONB field across all 6 items
owner: Đ44 + Đ24 (joint)
must_resolve_before_implementation_planning: FALSE
must_resolve_before_implementation_execution: TRUE
gate_classification: planning-level

3.5 X-4 — Enum implementation strategy

id: X-4
title: enum implementation strategy (PG enum type vs Đ24 lookup table FK)
affected_p0_items: [P0-2, P0-3, P0-4, P0-5, P0-6]
options:
  option_1_recommended:
    name: dieu24_lookup_table_fk
    description: Đ24 lookup table FK for vocabulary discipline; enum values managed via Đ24
    pros: vocabulary discipline; matches risk/coverage §5.1 X-4 recommendation; supports Đ24 ratification path
    cons: more joins; lookup table maintenance
  option_2:
    name: pg_enum_type
    description: native PG enum type per field
    pros: built-in PG enforcement; smaller storage
    cons: PG enum migration is heavy (ALTER TYPE); brittle for evolving vocabulary
  option_3:
    name: text_with_check_constraint
    description: text column + CHECK constraint listing values
    pros: easy to evolve
    cons: CHECK constraint becomes long; no vocabulary registry
recommendation: option_1 (Đ24 lookup FK)
risk_if_unresolved: medium — affects every enum field across all 6 items
owner: Đ24 vocab owner + Đ44 family registry custodian
must_resolve_before_implementation_planning: FALSE
must_resolve_before_implementation_execution: TRUE
gate_classification: planning-level
dependent_on: Đ24 ratification readiness for the enum sets referenced (state, verdict, kind, status, signature_kind, validation_state, operation_kind, target_table, verify_kind, axis_1_status, axis_2_status, axis_1_drift_unit, reviewer_kind)

3.6 X-6 — dot_pair_signature shape

id: X-6
title: dot_pair_signature table shape (shared across P0-3 and P0-4)
affected_p0_items: [P0-3, P0-4]
options:
  option_1_recommended:
    name: shared_table_with_signature_kind_enum_and_cross_reference_fks
    description: single dot_pair_signature table; signature_kind enum distinguishes executor_cut / verifier_cut / executor_verify / verifier_verify; cross_reference_change_set_id and cross_reference_verify_result_id (nullable) carry the targeting reference
    pros: shared schema across P0-3 + P0-4 per Đ44 Step 2 joint ratification; allows uniform signature audit and revocation
    cons: nullable cross-reference fields; signature_kind enum must distinguish targets cleanly
  option_2:
    name: separate_tables_per_kind
    description: distinct tables for cut_signature and verify_signature
    pros: cleaner per-domain FK; no nullable cross-reference fields
    cons: duplicates schema; complicates uniform signature lifecycle management
  option_3:
    name: jsonb_signatures_on_each_record
    description: store signatures as JSONB on cut_change_set and verify_result directly
    pros: minimal schema surface
    cons: no joinable signature table; revocation/queries weak; criterion 28 audit weaker
recommendation: option_1 (shared table; already designed in P0-3 §4.3)
risk_if_unresolved: medium-high — affects how criterion 28 enforcement is wired
owner: G-4 DOT Registry Custodian + Đ44 family registry custodian
must_resolve_before_implementation_planning: FALSE (shape already documented; final polish at planning)
must_resolve_before_implementation_execution: TRUE
gate_classification: planning-level (design has the shape; planning finalizes specifics like signature_payload column form)

3.7 X-7 — Canonicalization rule v0.1

id: X-7
title: canonicalization rule v0.1 (used by axis_1 drift computation and source_span ↔ axis_1_drift_unit conversion)
affected_p0_items: [P0-2 (source_span conversion), P0-4 (axis_1 drift computation)]
options:
  option_1_recommended:
    name: markdown_default_NFC_LF_trim
    description: default markdown canonicalization rule = NFC unicode normalization + LF line endings + trailing whitespace trim
    pros: simple, deterministic; matches P0-4 §6 recommendation; sufficient for cutter's typical markdown/law artifacts
    cons: not appropriate for code or binary artifacts (per-source_kind extension is FUTURE)
  option_2:
    name: ast_node_for_code_FUTURE
    description: per-source_kind ast_node canonicalization for code artifacts (FUTURE)
    pros: semantically correct for code
    cons: out-of-scope for v0.1; requires per-source_kind parser
  option_3:
    name: byte_canonicalization
    description: byte-level canonicalization without normalization
    pros: deterministic
    cons: CRLF/BOM differences inflate drift; not appropriate for cutter's markdown
recommendation: option_1 (NFC + LF + trim for markdown v0.1); option_2 (ast_node) FUTURE per source_kind via D4 capability intake
risk_if_unresolved: HIGH — directly affects axis_1 drift detection; ghost drift risk if rule changes mid-cycle
owner: Đ24 vocab owner (rule ratification) + Đ44 family ratifier
must_resolve_before_implementation_planning: FALSE (logical placeholder accepted at Đ32; full prose ratification deferred to Đ24)
must_resolve_before_implementation_execution: TRUE (prose must be Đ24-ratified before any real CUT)
gate_classification: planning-level for logical placeholder; execution-level for Đ24-ratified prose
dependent_decisions: X-A depends on X-7 (alignment + conversion logic uses the rule)

3.8 X-8 — Rollback test plan requirement

id: X-8
title: rollback test plan documentation + dry-run execution
affected_p0_items: [P0-3, P0-4]
options:
  option_1_recommended:
    name: documented_and_dry_run_before_first_real_cut
    description: rollback test plan documented during implementation planning; dry-run with synthetic data executed before first real CUT (i.e., before migration execution); plan covers scripted rollback per affected_row scenarios, verify-triggered rollback chain, rollback failure recovery, signature revocation cascade
    pros: validates rollback path before production exposure; matches P0-3 §12 + P0-4 §15
    cons: adds an execution precondition (does not block planning opening)
  option_2:
    name: post_execution_validation
    description: rollback path validated only on first real production rollback
    pros: faster path to production
    cons: HIGH risk of audit/data loss; not acceptable given criterion 28 binding
  option_3:
    name: no_explicit_test_plan
    description: rely on application-layer rollback logic without dedicated test plan
    pros: minimal
    cons: rejected for HIGH-risk items
recommendation: option_1 (documented + dry-run before first real CUT)
risk_if_unresolved: HIGH at execution time — rollback fidelity unverified
owner: G-4 DOT Registry Custodian + Đ32 (HIGH-risk path)
must_resolve_before_implementation_planning: FALSE (plan can be authored during planning)
must_resolve_before_implementation_execution: TRUE (plan documented + dry-run executed)
gate_classification: planning-level (authoring) + execution-level (dry-run)

---

4. Aggregate Gate Classification

decisions_blocking_implementation_planning_opening:
  count: 1
  entries:
    - X-A: source_span unit ↔ axis_1_drift_unit alignment

decisions_blocking_implementation_execution_only:
  count: 7
  entries:
    - X-1: schema placement
    - X-2: primary ID form
    - X-3: JSONB validation policy
    - X-4: enum implementation strategy
    - X-6: dot_pair_signature shape final polish
    - X-7: canonicalization rule v0.1 (prose ratification by Đ24)
    - X-8: rollback test plan documented + dry-run executed

5. Recommended Owners Summary

Owner	Decisions owned
Đ24 vocab owner	X-A (joint), X-4, X-7
Đ44 family registry custodian	X-A (joint), X-1, X-2, X-4, X-6
Đ33/Đ43 schema authority	X-1
G-4 DOT Registry Custodian	X-6, X-8
Đ32 (HIGH-risk path)	X-8 (review)

6. Conclusion

total_cross_cutting_decisions: 8
design_level_blockers_for_planning: 1 (X-A)
planning_level_blockers_for_execution: 7 (X-1, X-2, X-3, X-4, X-6, X-7, X-8)
execution_blockers_beyond_planning: subset of above + operational seat naming + DOT-pair registration (tracked in Đ32 report)

implementation_planning_signal: conditional_open
  condition: X-A closed jointly by Đ24 + Đ44 (recommendation = byte source_span + canonical_token drift with conversion via X-7 rule)

implementation_execution_signal: blocked
  reason: per Đ32 review master §7; full execution gate requires all 8 cross-cutting decisions closed plus operational preconditions

7. Explicit Confirmation

no_ddl_written: true
no_sql_written: true
no_canonicalization_rule_prose_written: true
no_signing_scheme_primitives_written: true
no_migration_executed: true
no_pg_mutation: true
no_qdrant_mutation: true
no_data_writes: true
no_implementation_planning: true
no_implementation_execution: true
no_migration_design_file_modified: true
no_previous_phase_file_modified: true
output_form: cross_cutting_decision_register_in_markdown_only