dot-iu-cutter v0.2 — P0-2 GOV Decision Register

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.2-design/dot-iu-cutter-v0.2-p0-2-gov-decision-register-2026-05-16.md
revision: r1
date: 2026-05-16
author: Agent (Claude Code CLI, Opus 4.7 1M)
phase: v0.2 — P0-2 GOV register (REGISTRATION ONLY; not resolution)
status: ALL OPEN — decision owners are councils/GPT; Agent does NOT self-close

Registers the three governance decisions that block P0-2 DDL freeze but do not block P0-2 design start (GPT BR-6 absorption review, 2026-05-16). Recommendations are Agent leans for GPT/council consideration, not resolutions.

---

GOV-1 — Address-coining rule for split children / merge result

question: how is proposed_canonical_address derived for result blocks?
context: public.tac_logical_unit.canonical_address syntax = D{doc}-DIEU{N}-{S|ROOT}[-P{n}][-{n}]
         (Option-D reconciliation, immutable SSOT). Split needs 2+ new addresses; merge needs 1.
options:
  O1_extend_grammar: append/extend the -P{n} / -{n} tail of the parent address
    pro: human-traceable lineage in the address itself; minimal namespace churn
    con: deep split chains grow long tails; tail semantics must stay v1-valid
  O2_new_sequence: coin a fresh address in the document's sequence, lineage via alias only
    pro: addresses stay short/uniform; lineage fully carried by alias trail (INV-4)
    con: address no longer self-describes lineage; relies on alias resolution
  O3_hybrid: extend for split (lineage matters), new-sequence for merge (synthesis)
    pro: matches the semantic difference between split (derive) and merge (synthesize)
    con: two rules to specify/validate
agent_lean: O3_hybrid (split→extend, merge→new-sequence) — pending Đ24 ratification
owner: Đ24 (canonical-address grammar council) + GPT
deadline: before P0-2 DDL freeze (NOT before design start)
impact_if_unresolved: proposed_canonical_address column SHAPE/validation cannot be
  frozen; P0-2 DDL freeze blocked. Design proceeds (column exists; semantics open)
blocks_design_start: NO

GOV-2 — Authority inheritance across split/merge

question: what authority does a result block inherit (split of 'enacted' unit → ?;
          merge of mixed-authority units → ?)
context: Phase α authority ∈ {draft, enacted, runtime}; INV-2 = no escalation w/o re-enactment
options:
  O1_demote_to_draft: all results start 'draft'; must be re-enacted to regain authority
    pro: safest; never silently propagates enacted authority through a topology change
    con: every split/merge of enacted law forces a re-enactment cycle
  O2_inherit_min: result inherits the MINIMUM authority among its origin(s)
    pro: monotone, no escalation (INV-2 satisfied); less churn than O1 for splits
    con: merge of {enacted, draft} → draft may surprise authors
  O3_inherit_with_gate: inherit predecessor authority but flag result for mandatory
        re-enactment review before it is treated as enacted
    pro: preserves intent while honoring INV-2 via the review gate (INV-5)
    con: most complex; couples to P0-6 review semantics
agent_lean: O1_demote_to_draft (simplest, strictly INV-2-safe) — pending Đ0-G ratification
owner: Đ0-G (authority semantics council) + GPT
deadline: before P0-2 DDL freeze (NOT before design start)
impact_if_unresolved: proposed_authority default/validation cannot be frozen; DDL freeze blocked
blocks_design_start: NO

GOV-3 — manifest ↔ alias linkage

question: does the manifest carry an explicit alias-linkage column, or is alias emission
          purely event-backed at P1?
context: canonical_address_alias is Phase-α live + empty; alias writes are P1
options:
  O1_event_backed_no_coupling: NO manifest→alias column; P1 derives alias rows from
        operation_kind + block_role + target_unit_id + proposed_canonical_address
    pro: zero coupling; no alias writes needed to test P0-2; matches GPT initial lean
    con: alias derivation logic lives entirely in P1 (must be specified there)
  O2_explicit_linkage: add a soft alias_ref column on result blocks
    pro: explicit audit linkage proposal→alias
    con: premature coupling before alias write pathways exist; needs alias writes to test
agent_lean: O1_event_backed_no_coupling (matches GPT BR-6 review initial_lean)
owner: GPT
deadline: before P0-2 DDL freeze (NOT before design start)
impact_if_unresolved: whether an alias_ref column exists is undecided → DDL freeze blocked.
  Current design assumes O1 (no coupling) consistently
blocks_design_start: NO

Summary Table

GOV	Topic	Owner	Agent lean	Blocks design start	Blocks DDL freeze
GOV-1	address-coining	Đ24 + GPT	O3 hybrid	No	Yes
GOV-2	authority inheritance	Đ0-G + GPT	O1 demote-to-draft	No	Yes
GOV-3	manifest↔alias linkage	GPT	O1 event-backed (no coupling)	No	Yes

all_three: required_before_DDL_freeze
none: blocks_design_start
agent_self_close: FALSE   (owners = councils/GPT)

Hard Boundaries

no_GOV_self_closed: TRUE (registration only; recommendations are leans, not rulings)
no_DDL_written: TRUE
output_form: p0_2_gov_decision_register

End of GOV decision register.