dot-iu-cutter v0.5 — Three Existing Cut Documents: Merge & Storage Design

Date: 2026-05-17 · Status: DESIGN ONLY — no merge, no write, no schema change. Parent: design-master.

1. The three documents & where they are stored (grounded)

doc_code	rows	tier shape	address prefix
DIEU-28	27	root/section/unit (complete)	D38-DIEU28-…
DIEU-32	23	tier blank	D38-DIEU32-…
DIEU-35	36	tier blank	D38-DIEU35-…

• Logical-unit SSOT: public.tac_logical_unit (Postgres directus). Columns: id uuid, canonical_address, doc_code, parent_id, sort_order, section_type, section_code, tier, authority, lifecycle_status, canonical_address_format_version, identity_profile jsonb, timestamps.
• Cut/verify governance + manifest: cutter_governance.* (12 tables) — currently holds the one trial IU's +15 ledger (DIEU-28 D38-DIEU28-S3-P1); the rest are logical units not yet cut through the v0.4 pipeline.
• All three uniformly authority=draft, lifecycle_status=draft_only, canonical-address-v1.

2. Merge / storage destination for a new full document (proposed)

• Same corpus, co-resident: the new document's IUs are inserted into the same public.tac_logical_unit with a distinct config-driven doc_code (e.g. HIENPHAP-2013, not hardcoded — supplied by config, OD-8) and a distinct canonical-address namespace; its cut/verify governance lands in the same cutter_governance.* family, exactly as for DIEU-28. No separate store, no NoSQL, no new schema.
• Co-residency invariant: documents are partitioned by doc_code + canonical-address prefix; the cutter's deterministic entry_id (uuid5 of idempotency key over signal/iu_ref/spec) guarantees no cross-document entry collision. G-CUT-ONCE remains per-IU.
• Address namespace (OD-4/OD-8): canonical-address-v1 grammar is D38-DIEU<NN>-…. A constitution needs a Chương level and its own document prefix; defining that grammar/prefix is a format decision (separately gated — no format/schema change in v0.5).

3. Existing-corpus normalisation question (OD-9)

DIEU-32 and DIEU-35 have blank tier (59/86 rows); only DIEU-28 is fully tiered. Before or independent of a full-document trial, GPT must decide whether to normalise the existing three documents' tier/shape (a data-quality task, itself a separately-designed/authorized change — not done here) so merge/query semantics are uniform. v0.5 only records the inconsistency; it proposes no UPDATE.

4. What "merge" means here (clarified)

There is no row-level merge/dedup across documents — documents are independent doc_code partitions co-resident in one table/schema. "Merge/store with the three existing" = append the new document as a fourth co-resident doc_code in the same SSOT, queryable alongside the others, with the same governance ledger shape. Any future cross-document linkage (citations between the constitution and DIEU-* dossier) would be a separate dependency/alias design (decision_backlog_dependency / canonical_address_alias — alias deferred since v0.4; no alias writes).

Boundaries / Git

Design only; no merge/write/schema/alias. Git main · e93424b5ff7fa5e4b8406131977ce4339cd0856a · clean (0 lines). No hardcoded doc_code/destination (config-driven). SQL SSOT; vector/NoSQL projection/search only; no NoSQL store introduced. Open: OD-4, OD-8, OD-9. Next = GPT review.