Incomex AI Portal
KB-14D3

dot-iu-cutter v0.2 — BR-5 Đ24 canonical_address v1 Ratification Request (2026-05-15)

15 min read Revision 1
dieu44-trien-khaidot-iu-cutterv0.2br-5dieu24ratification-requestcanonical-addressv1planning-only2026-05-15

dot-iu-cutter v0.2 — BR-5 Đ24 canonical_address v1 Ratification Request

document_path: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-5-dieu24-canonical-address-v1-ratification-request-2026-05-15.md
revision: r1
date: 2026-05-15
author: Agent (Claude Code CLI, Opus 4.7 1M)
sovereign: User / anh Huyên
verifier: GPT (Đ32 HIGH-risk path — anticipated)
secondary: Opus
governance_review_required: Đ24 (vocabulary owner) + Đ32 (risk class)
phase: v0.2 planning — BR-5 ratification request (planning only; no mutation)
BR_5_status: pending_gpt_review
mutation_performed: false
ddl_written: false

§1 — Purpose

Request Đ24 ratification of the production canonical_address syntax as the formal v1 of the canonical_address format vocabulary, so that v0.2 Phase α can set a binding DEFAULT for the new canonical_address_format_version column.

This document presents the syntax, its observed evidence in production, the proposed version string, the grammar definition, validation examples, and the explicit non-goals (non-law artifact formats are explicitly deferred).

§2 — Background

context:
  - v0.1 production execution (2026-05-15) deployed schema cutter_governance + 5 tables
  - finding F-2: public.tac_logical_unit.canonical_address column PRE-EXISTS with a production syntax that differs from the v0.1 P0-1 design's proposed syntax
  - GPT selected reconciliation Option D (Hybrid phased)
  - Phase α plan: ADD COLUMN canonical_address_format_version text NOT NULL DEFAULT '<TBD-Đ24-ratified>'
  - the DEFAULT value MUST be a string that Đ24 ratifies as the canonical name of the version

what_Đ24_decides:
  - whether the observed syntax is the official v1
  - the version string identifier
  - the formal grammar to attach to the version
  - whether amendments (e.g. for sub-segments past Sn-Pn-N) are within v1 or trigger v1.1

what_Đ24_is_NOT_being_asked:
  - to ratify non-law artifact formats (deferred per §8)
  - to ratify display rendering of addresses (handled separately by a presentation-layer renderer)
  - to ratify authority semantics (handled by Đ0-G under BR-4)

§3 — Observed Production Syntax (verbatim evidence)

3.1 Pattern observed across 86 production rows in public.tac_logical_unit

D{doc}-DIEU{N}-{S{seg}|ROOT}[-P{n}][-{n}]

3.2 Verified examples (production data, sampled in BR-2/3/7 discovery)

D38-DIEU28-ROOT
D38-DIEU28-S0
D38-DIEU28-S1
D38-DIEU28-S10
D38-DIEU28-S11
D38-DIEU28-S1-P1
D38-DIEU28-S1-P2
D38-DIEU28-S2-P5
D38-DIEU28-S3-P5
D38-DIEU28-S8-P1
D38-DIEU32-ROOT
D38-DIEU32-S0
D38-DIEU32-S4-P1
D38-DIEU32-S4-P2
D38-DIEU32-S4-P3
D38-DIEU35-ROOT
D38-DIEU35-S0
D38-DIEU35-S4-P1
D38-DIEU35-S4-P1-1
D38-DIEU35-S4-P1-2
D38-DIEU35-S4-P1-3
D38-DIEU35-S15

3.3 Document scope present in production (3 documents)

DIEU-28, DIEU-32, DIEU-35  — all under doc id D38
(Đ44 itself is NOT yet in tac_logical_unit — there are no D38-DIEU44-… addresses today)

3.4 Sister-table corroboration

Identical syntax used in:

  • public.information_unit.canonical_address (98 rows)
  • public.unit_edit_draft.canonical_address (13 rows)
  • public.event_outbox.canonical_address (44,726 rows)
  • sandbox_tac.logical_unit.canonical_address (76 rows; sandbox uses D38-C1A-… — same outer structure, different section_code slot)

All 7 sister tables across public schema use the same outer syntax. This is a system-wide convention, not a tac-only convention.

§4 — Proposed Version String

proposed_version_string: canonical-address-v1
also_acceptable: cav1   (short form for index payloads)
NOT_recommended: d38-v1   (couples version identifier to a specific doc id; not future-proof)

rationale:
  - the version applies to ALL canonical_address values in ALL TAC-derived tables, not just D38-prefixed ones
  - decoupling the version label from the doc-id prefix lets future docs (e.g., D40, D41) inherit v1 without renaming
  - 'canonical-address-v1' is self-documenting; 'cav1' is the compact form for jsonb / index payloads

binding_request_to_Đ24:
  ratify "canonical-address-v1" as the formal vocabulary identifier for the syntax in §5 below.
  (or substitute the Đ24-preferred label; Agent is non-binding here.)

§5 — Grammar Definition

(* canonical-address-v1 grammar — for ratification by Đ24 *)

canonical_address    = doc_prefix , "-" , section_prefix , [ "-" , subsegment_chain ] ;

doc_prefix           = "D" , doc_id ;
doc_id               = digit , { digit } ;
                       (* observed: 38; future doc ids in same form *)

section_prefix       = root_marker | numbered_section ;
root_marker          = "DIEU" , dieu_number , "-" , "ROOT"
                     | section_code_token , "-" , "ROOT" ;

numbered_section     = "DIEU" , dieu_number , "-" , section_token
                     | section_code_token , "-" , section_token ;

dieu_number          = digit , { digit } ;
                       (* observed: 28, 32, 35; future: any positive integer *)

section_code_token   = uppercase_letter , { uppercase_letter | digit } ;
                       (* observed in sandbox: "C1A"; reserved for chapter-style addresses *)

section_token        = "S" , digit , { digit } ;
                       (* observed: S0, S1, S10, S11, S15, … *)

subsegment_chain     = subsegment , [ "-" , subsegment_chain ] ;
subsegment           = paragraph_segment | numeric_segment ;
paragraph_segment    = "P" , digit , { digit } ;
                       (* observed: P1..P7 *)
numeric_segment      = digit , { digit } ;
                       (* observed: 1, 2, 3 — used as third-level depth after a P-segment, e.g., S4-P1-3 *)

(* terminals *)
digit                = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9" ;
uppercase_letter     = "A" | "B" | ... | "Z" ;

5.1 Storage encoding rules

character_set: ASCII only (no Vietnamese diacritics)
case_sensitivity: case-sensitive; canonical form uses UPPERCASE for doc_prefix, section_prefix, and subsegment tokens; numeric digits as-is
whitespace: NONE (no spaces inside an address)
separator: hyphen "-" between tokens
max_length: not bounded by v1; practical maximum observed ≤ 20 characters; UNIQUE constraint enforces practical bound
nullability_in_schema: NOT NULL on tac_logical_unit, information_unit, unit_edit_draft, event_outbox, iu_notification_event, sandbox_tac.logical_unit; NULL allowed only on birth_registry (current production state)
uniqueness_scope_in_schema: GLOBAL per table (each table has its own UNIQUE on canonical_address)
collision_policy_at_storage_layer: rejected by DB unique index

5.2 Storage canonicality

duplicate_storage_in_identity_profile_jsonb (BR-2 finding):
  - 27 of 86 rows in tac_logical_unit duplicate canonical_address inside identity_profile
  - same value; cosmetic only; NOT part of v1 ratification
  - recommendation: Đ24 ratifies that the column is the authoritative source; the jsonb mirror is a redundancy that can be cleaned up in a non-ratification cosmetic pass

§6 — Validation Examples

6.1 Valid under v1 (must round-trip the grammar)

D38-DIEU28-ROOT            ✓ root marker, DIEU-style
D38-DIEU28-S0              ✓ section 0
D38-DIEU28-S10             ✓ multi-digit section
D38-DIEU28-S1-P1           ✓ section + paragraph
D38-DIEU35-S4-P1-3         ✓ section + paragraph + numeric subsegment
D38-DIEU32-S2-P4           ✓
D38-C1A-ROOT               ✓ section_code_token form (sandbox-observed; reserved for chapter addresses)
D38-C1A-S4-P7              ✓
D40-DIEU44-ROOT            ✓ future-doc-id; future-DIEU; same form
D38-DIEU44-S5              ✓ future-DIEU under existing doc

6.2 Invalid under v1 (would fail grammar)

D38-DIEU28-S2.1            ✗ uses "." as separator; v1 uses only "-"
Đ44§5.3.1                  ✗ Vietnamese diacritic; v1 is ASCII-only
d38-DIEU28-S2              ✗ lower-case doc prefix; v1 canonical is upper-case
D38_DIEU28_S2              ✗ underscore; v1 separator is "-"
D38-DIEU-28-S2             ✗ hyphen between DIEU and number; v1 uses "DIEU{N}" concatenated
D38 DIEU28 S2              ✗ whitespace; v1 forbids
D38-DIEU28-                ✗ trailing separator
""                         ✗ empty string; rejected at column level (existing CHECK on 3 sister tables; tac uses NOT NULL only — but empty would still be a constraint violation if a CHECK is later added)
NULL                       ✗ on NOT-NULL tables

6.3 Edge cases (Đ24 to decide)

edge_case_1: D38-DIEU0-ROOT (DIEU number = 0)
  proposed_decision: accept (grammar permits; semantically "Đ0" exists in the vocabulary per Đ0-G context)

edge_case_2: D38-DIEU28-S999-P999-99999 (very deep nesting)
  proposed_decision: accept under v1; deep nesting is not bounded by grammar; storage UNIQUE constraint handles uniqueness

edge_case_3: D38-DIEU28-X1 (non-S, non-P segment with letter)
  proposed_decision: REJECT under v1 (grammar only allows S{n} / P{n} / numeric for sub-segments); reserve letter-prefixed segments for v1.1

edge_case_4: sandbox addresses (D38-C1A-…)
  proposed_decision: accept under v1 — section_code_token (uppercase letter+digit) is part of v1 grammar; sandbox rows are valid v1 addresses

§7 — Relationship to Display Renderer

storage_form_(authoritative): D38-DIEU28-S2-P1
display_form_(human-facing): may be rendered as "Đ28 §2.1" by a presentation-layer renderer for legal-citation surfaces (D11 §4.13 consumer contract)

renderer_lives_in: out of v0.2 P0 scope; recommended placement: Nuxt SSR / client (the same layer that currently reads canonical_address per BR-3 §9)
renderer_v0_responsibility: read the canonical_address column, parse via the v1 grammar, render the human form
ratification_does_NOT_couple_storage_to_display: v1 grammar is the STORAGE syntax; display is downstream and separately governed
v1_grammar_changes_do_NOT_require_renderer_changes_unless: storage syntax changes substantively (e.g., new segment types added in v1.1)

§8 — Non-Law Artifact Format — Explicitly Deferred

non_law_artifact_formats:
  - design artifacts (e.g., "dot-iu-cutter-v0.1/D6/§4.2" per P0-1 §6)
  - code symbols (e.g., "tac:fn_iu_create" per P0-1 §6)
  - reports, runbooks, runtime IUs
status: EXPLICITLY DEFERRED from v1
rationale:
  - no production data uses non-law forms yet
  - introducing them in v1 grammar without observed usage would speculate
  - they belong to v1.1 or a separate v-NL-1 vocabulary
recommended_Đ24_action_on_this: acknowledge deferral; create a Đ24 backlog item for "canonical_address non-law format v1.1" to be ratified when a concrete production use-case emerges

§9 — Compatibility With Phase α Plan

phase_alpha_proposed_default:
  ALTER TABLE public.tac_logical_unit
    ADD COLUMN canonical_address_format_version text NOT NULL DEFAULT 'canonical-address-v1';
  (DDL not authored in this document; shown only to clarify the ratification request impact)

phase_alpha_proposed_default_for_sister_tables: NONE — Phase α DOES NOT add this column to sister tables (per Option D scope restriction).

backfill_for_existing_86_rows:
  - column added with DEFAULT 'canonical-address-v1' — all 86 existing rows get this value at column-add time, no separate UPDATE needed
  - trivial; zero risk

mirror_on_sandbox_tac.logical_unit:
  - additive column with same DEFAULT, per BR-7 Option II
  - 76 rows backfilled via DEFAULT at column-add time

§10 — Đ24 Council Review Notes (anticipated)

question_1: Why ratify the production syntax now, when no Đ44-prefixed addresses exist?
answer_proposal: v0.2 Phase α is adding canonical_address_format_version; the DEFAULT needs Đ24's name. Ratifying the syntax that IS in production (covering 86 + 98 + 13 + 44,726 + 76 rows) locks in the version label. Future Đ44 rows will inherit the same v1 by default.

question_2: Why ASCII-only (no Vietnamese diacritics)?
answer_proposal: storage form needs to be operable across all infrastructure layers (PG, Nuxt, JSONB, indexes, sed/grep tooling). The HUMAN display form ("Đ28 §2.1") is delivered by a presentation-layer renderer. Storage is ASCII; display is i18n. This decouples the two concerns cleanly.

question_3: How is sandbox's C1A token reconciled with DIEU-style?
answer_proposal: grammar accepts both `DIEU{N}` and `{section_code_token}` (uppercase letter+digit) in the section_prefix slot. Sandbox uses C1A for chapter-style addresses; production uses DIEU{N} for article-style. Both are valid v1.

question_4: Will v1 lock us out of future structural changes?
answer_proposal: NO. v1 is reserved for the current syntax; v1.1 or v2 can introduce new segment types or separators (e.g., letter-prefixed segments per §6.3 edge case 3). The canonical_address_format_version column makes the per-row version explicit, supporting safe coexistence.

question_5: Should event_outbox and other sister tables get the format_version column too?
answer_proposal: NOT IN v0.2 Phase α. Sister tables are out of Option D scope. A future phase may extend the format_version concept to sister tables once a concrete need emerges (e.g., format migration).

§11 — Hard Boundaries

no_DDL_written: TRUE
no_SQL_mutation: TRUE
no_ALTER_TABLE: TRUE
no_INSERT_UPDATE_DELETE: TRUE
no_migration: TRUE
no_change_to_tac_logical_unit: TRUE
no_change_to_sandbox_tac: TRUE
no_change_to_cutter_governance: TRUE
no_change_to_sister_tables: TRUE
no_design_advanced_beyond_BR_5: TRUE
no_deploy: TRUE
no_phase_alpha_design_started: TRUE
BR_5_status: pending_gpt_review (then Đ24 council pass)
output_form: br_5_ratification_request_documentation_only

§12 — Cross-References

br_4_companion: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-4-authority-backfill-rule-design-2026-05-15.md
br_2_3_7_consolidated: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-2-3-7-discovery-report-2026-05-15.md
br_4_5_closure_report: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-4-5-closure-readiness-report-2026-05-15.md
reconciliation_report: knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-canonical-address-reconciliation-report-2026-05-15.md
v0_1_p0_1_design (proposed-but-superseded syntax): knowledge/dev/laws/dieu44-trien-khai/migration-design/dot-iu-cutter-v0.1-p0-1-canonical-address-migration-design-2026-05-15.md
v0_2_scope_backlog: knowledge/dev/laws/dieu44-trien-khai/planning/dot-iu-cutter-v0.2-scope-backlog-2026-05-15.md
production_evidence_schema_snapshot: /opt/incomex/backups/dieu44_exec_2026-05-15/directus_schema_pre_20260515T141429Z.sql  sha256 638307fd62d4b1aa087ce7f70f42112c4c6185a2e44d8144a1d859029515668a

End of BR-5 Đ24 ratification request.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/v0.2-planning/dot-iu-cutter-v0.2-br-5-dieu24-canonical-address-v1-ratification-request-2026-05-15.md