dot-iu-cutter v0.1 — Đ44 Family Registry Closure Package

Date: 2026-05-15 Status: PROPOSED_FOR_DIEU44_RATIFICATION Trigger: Council Ratification Outcome (5 governance gaps ratified_with_notes) → Đ44 + Đ24 parallel closure phase Baseline: rev5d §3.5 (Đ44 controlled draft) + D7 UOSL Compatibility Note + P0 Schema Planning Package Scope: GOVERNANCE CLOSURE PROPOSAL ONLY. No code, no DDL, no SQL, no migration, no PG mutation, no Qdrant mutation, no schema change, no P0 Migration Design.

1. Hard Boundaries

no_code: true
no_ddl: true
no_sql: true
no_schema_change: true
no_migration: true
no_pg_mutation: true
no_qdrant_mutation: true
no_implementation: true
no_p0_migration_design_started: true
no_previous_file_modified: true
no_design_or_planning_or_closure_or_ratification_file_modified: true
package_purpose: prepare_dieu44_family_registry_ratification_only

2. Đ44 / UOSL Status Statement (binding)

dieu44_status: CONTROLLED_DRAFT
dieu44_role: COMPATIBILITY_TARGET (not enacted law)
treat_as_enacted: false
silent_field_invention: forbidden
new_top_level_family_creation_outside_dieu44_governance: forbidden
parallel_family_registry: forbidden
this_package_creates_schema: false
this_package_writes_ddl: false
this_package_mutates_pg: false
this_package_proposes_families_for_dieu44_to_ratify: true

Per rev5d §3.5: Đ44 is the controlled draft and compatibility target. This package proposes Family Registry entries for Đ44 governance to ratify; it does NOT add anything to Đ44 directly, and it does NOT treat draft fields as enacted.

3. Purpose

Liệt kê và đặc tả 6 Family Registry candidates mà Đ44 governance phải ratify trước khi P0 Migration Design phase mở. Mỗi family được mô tả ở mức conceptual (purpose, source, OQC check, G1–G12 mapping hints, schema gap) — không có DDL, không có cụ thể schema content.

4. Family Registry Candidates Summary Table

#	Family	Source deliverables	Related P0 item	P0 required?	Recommended status
1	`manifest_envelope`	D2 §4.1, §4.2	P0-2	YES (P0)	proposed_for_dieu44_ratification
2	`manifest_unit_block`	D2 §4.2	P0-2	YES (P0)	proposed_for_dieu44_ratification
3	`cut_change_set`	D1 §4.8	P0-3	YES (P0)	proposed_for_dieu44_ratification
4	`verify_result`	D1 §4.7, §4.14	P0-4	YES (P0)	proposed_for_dieu44_ratification
5	`governance_event` (umbrella for `review_decision`, `decision_backlog_entry`, signal events)	D2 §4.6, D5 §4.2, D9 §4.8	P0-5, P0-6	YES (P0)	proposed_for_dieu44_ratification
6	`semantic_thread`	D9 §4.1, §4.2	P2 (later, not P0)	NO (P2)	proposed_for_dieu44_ratification_at_p2_phase

Total: 6 families. 5 are P0-blocking; 1 (semantic_thread) is P2 — can be deferred to a later Đ44 phase but proposed here so Đ44 governance sees the full picture.

5. Family Candidates — Detailed

5.1 `manifest_envelope`

Purpose: Header envelope for a cut manifest emitted by MARK and consumed by REVIEW + CUT. Manifest-as-code (Đ38) artifact. SSOT for cutter manifests.

Source deliverables:

D2 §4.1 — Manifest is code (versioned, diffable).
D2 §4.2 — Header fields (manifest_id, manifest_version, source_path, source_revision, source_kind, tool_revision, emitted_by, emitted_at, C1A_rule_refs, body_source_policy, collision_status, risk_class, review_required).
D1 §4.4 — MARK stage emits manifest envelope.

Related P0 item: P0-2 (manifest_envelope + manifest_unit_block).

P0 required? YES. P0-2 cannot enter migration design without this family ratified.

Owner law / compatibility target:

Primary: Đ44 / UOSL (Family Registry).
Cross-law: Đ38 (manifest-as-code authority), Đ24 (header field vocabulary).

OQC check (Object Qualifying Core):

OQC field	Maps to manifest_envelope
identity	manifest_id (deterministic ID)
version	manifest_version (semver-style)
provenance	emitted_by + emitted_at
classification	source_kind (Đ24 enum)
governance state	risk_class, review_required

OQC check: PASS (all OQC fields have corresponding manifest_envelope fields).

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	manifest_id
G2 (classification)	source_kind, C1A_rule_refs
G3 (relations)	source_path, source_revision
G4 (publication)	(inherits from underlying source publication; envelope itself is not published as IU)
G5 (governance state)	risk_class, review_required, collision_status
G6 (semantics)	body_source_policy hints
G7 (provenance)	emitted_by, emitted_at, tool_revision

Mapping is conceptual; gaps recorded (§5.1 open schema gap below).

Open schema gap:

Manifest envelope is a NEW family hint; not an existing UOSL family.
Body_source_policy enum vocab requires Đ24 ratification (cross-link Đ24 closure package).
risk_class vocab requires Đ24 ratification (cross-link).
Đ44 must decide if manifest_envelope is a top-level family or a sub-class under "Decision Artifact" umbrella.

Recommended registry status:

status: proposed_for_dieu44_ratification
maturity_proposed: M1 (defined, not yet enacted)
top_level_or_sub_class: deferred_to_dieu44_decision (recommend sub-class under "Decision Artifact" umbrella if Đ44 has one)

5.2 `manifest_unit_block`

Purpose: Per-IU block of a cut manifest. Child rows of manifest_envelope per Decision 5 (child rows + JSONB hybrid).

Source deliverables:

D2 §4.2 — Per-unit block fields (unit_local_id, source_span_start/end, title, section_type, unit_kind, parent_unit_id, hierarchy_depth, body_source_policy, C1A_rule_refs, three_question_test_result, cut_reason, confidence, length_flag, edge_readiness_notes, review_flags, semantic_role, candidate_edges, render_order, canonical_address).
User Decision Confirmation §4.5 (Decision 5 child rows + JSONB shape).

Related P0 item: P0-2 (joint with manifest_envelope).

P0 required? YES.

Owner law / compatibility target:

Primary: Đ44 / UOSL.
Cross-law: Đ38 (manifest-as-code), Đ24 (section_type/unit_kind/body_source_policy vocabulary), Đ39 (candidate_edges → universal_edges first), Đ0-G (birth gate readiness).

OQC check:

OQC field	Maps to manifest_unit_block
identity	unit_local_id (within-manifest); FK to envelope
version	inherits from envelope version
provenance	inherits from envelope emitted_by/at
classification	section_type, unit_kind
governance state	length_flag, review_flags, three_question_test_result

OQC check: PASS (with note: identity is composite — envelope + unit_local_id).

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	unit_local_id + canonical_address
G2 (classification)	section_type, unit_kind
G3 (relations)	parent_unit_id, hierarchy_depth, source_span_start/end
G4 (publication)	render_order, (publication membership inherited from underlying IU)
G5 (governance state)	length_flag, review_flags, three_question_test_result
G6 (semantics)	semantic_role, candidate_edges, edge_readiness_notes
G7 (provenance)	cut_reason, confidence

Mapping is conceptual; gaps in §5.2 open schema gap below.

Open schema gap:

semantic_role, canonical_address, candidate_edges, edge_readiness_notes — fields needing Đ24 vocab + first-class column placement; Đ44 governance must confirm placement (G6 group field family).
Child-row shape (per Decision 5) is the design intent; Đ44 must confirm composite identity pattern is acceptable.
C1A rule reference shape (JSONB list of rule IDs) — Đ44 must decide if JSONB acceptable for G2 classification field group.

Recommended registry status:

status: proposed_for_dieu44_ratification
maturity_proposed: M1
identity_pattern: composite (envelope_id + unit_local_id) — Đ44 confirm
top_level_or_sub_class: paired with manifest_envelope; recommend joint ratification

5.3 `cut_change_set`

Purpose: Per-CUT-execution record carrying rollback_key, references to all tac_logical_unit + tac_unit_version rows created/modified, and joint DOT-pair signatures.

Source deliverables:

D1 §4.8 — Rollback model (exact-key, no partial publish).
D1 §4.14 — DOT-pair dual signature.
G-4 ratification (both-signatures-required rule).

Related P0 item: P0-3 (cut_change_set + rollback_key).

P0 required? YES.

Owner law / compatibility target:

Primary: Đ44 / UOSL.
Cross-law: Đ38 (change-set as code), Đ32 (rollback risk surface), Đ37 (DOT-pair signing per G-4).

OQC check:

OQC field	Maps to cut_change_set
identity	change_set_id + rollback_key
version	change_set_version (if mutations occur post-cut; usually frozen post-publish)
provenance	executor_dot_signature + verifier_dot_signature + cut_timestamp
classification	(change-set is a new family kind)
governance state	publish_state, rollback_state

OQC check: PASS.

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	change_set_id, rollback_key
G3 (relations)	FK list to created/modified tac_logical_unit + tac_unit_version + manifest_envelope
G5 (governance state)	publish_state, rollback_state, risk_class
G7 (provenance)	executor_dot_signature, verifier_dot_signature, tool_revision (executor + verifier), cut_timestamp

Open schema gap:

DOT-pair dual signature record — Đ44 must confirm acceptable shape (separate signing row vs columns on change-set; cross-link with P0-3 §5.3 open decisions).
Rollback semantics for downstream signals (already-emitted health signals after CUT) — Đ44 + Đ37 cross-law decision.
Cascade rules with other change-sets — Đ44 must confirm cascade tracking field.

Recommended registry status:

status: proposed_for_dieu44_ratification
maturity_proposed: M2 (operational, in pilot)
top_level_or_sub_class: top-level (cut_change_set is a distinct artifact, unlike envelope which is decision-time)

5.4 `verify_result`

Purpose: VERIFY stage outcome — round-trip drift count, axis-2 coverage, DOT-pair dual signature, status (PASS/FAIL/NEEDS_HUMAN), findings.

Source deliverables:

D1 §4.7 — VERIFY stage.
D1 §4.14 — DOT-pair dual signature in REPORT.
G-4 ratification.

Related P0 item: P0-4 (verify_result).

P0 required? YES.

Owner law / compatibility target:

Primary: Đ44 / UOSL.
Cross-law: Đ38 (verify-as-code), Đ32 (verify failure risk), Đ37 (NEEDS_HUMAN escalation).

OQC check:

OQC field	Maps to verify_result
identity	verify_result_id; FK to manifest_envelope + cut_change_set
version	(usually frozen; immutable record of one verify event)
provenance	executor_dot_signature, verifier_dot_signature, verified_at, tool_revision
classification	status (PASS/FAIL/NEEDS_HUMAN)
governance state	escalation_status, axis_1_status, axis_2_advisory_status

OQC check: PASS.

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	verify_result_id
G3 (relations)	FK to manifest_envelope, cut_change_set
G5 (governance state)	status, escalation_status
G6 (semantics)	axis_1_drift_count, axis_2_coverage_score, axis_2_advisory_findings
G7 (provenance)	executor_dot_signature, verifier_dot_signature, verified_at, tool_revision

Open schema gap:

Axis-1 drift count semantics — byte-level vs line-level vs AST-node-level (cross-link P0-4 §5.4 open decision 4 + Gate 2 §4 item 3).
Axis-2 coverage score semantics — numeric (0–1) vs banded — Đ44 G6 group decision.
Findings JSONB schema — Đ44 must confirm JSONB is acceptable for G5 governance-state findings.
Canonical-form comparison spec for axis-1 — out of Đ44 scope (it's a verifier spec), but Đ44 must confirm verify_result can carry the comparison metadata.

Recommended registry status:

status: proposed_for_dieu44_ratification
maturity_proposed: M2 (operational, in pilot)
top_level_or_sub_class: top-level
joint_ratification_with: cut_change_set (recommended, since both share DOT-pair signature schema)

5.5 `governance_event` (umbrella family)

Purpose: Umbrella family for governance-trail artifacts that share envelope shape: review_decision (P0-6), decision_backlog_entry (P0-5), thread health signals (D9 §4.8), retrieval search-gap signals (D11 §4.9), security events (wrong_audience_result, dot_pair_drift, signature_failure, sweep_overdue).

Source deliverables:

D2 §4.6 — Review decision.
D5 §4.2 — Decision backlog entry envelope.
D9 §4.8 — Thread health signals.
D11 §4.9 — Search gap signals.
D3 §4.2 — Health signal catalog.
G-5 closure (security event class).

Related P0 item: P0-5 (decision_backlog_entry) + P0-6 (review_decision). Other governance event sub-kinds are P2/P3 (health signals, retrieval signals, security events).

P0 required? YES (for P0-5 and P0-6 sub-kinds). P2/P3 sub-kinds proposed in this same family for forward consistency.

Owner law / compatibility target:

Primary: Đ44 / UOSL.
Cross-law: Đ37 (governance event routing channels), Đ32 (high-risk events), Đ38 (event-as-code), Đ24 (event_kind vocabulary).

OQC check:

OQC field	Maps to governance_event
identity	event_id
version	event_version (if updatable; backlog entries are; review decisions are typically immutable)
provenance	emitted_by + emitted_at
classification	event_kind (Đ24 vocabulary)
governance state	status, risk_class

OQC check: PASS.

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	event_id
G2 (classification)	event_kind (review_decision / backlog_entry / health_signal / search_gap_signal / security_event)
G3 (relations)	FK to related manifest/unit/change-set/thread
G5 (governance state)	status, risk_class, owner
G6 (semantics)	findings (JSONB)
G7 (provenance)	emitted_by, emitted_at, source_discussion

Sub-kinds proposed in this family (per Đ44 decision on umbrella vs separate):

Sub-kind	P0/P1/P2/P3
`review_decision`	P0-6
`decision_backlog_entry`	P0-5
`thread_health_signal`	P2
`search_gap_signal`	P3
`wrong_audience_result_event`	P3 (HIGH risk class — special handling per G-5)
`sweep_overdue`	P2 (custodian audit)
`dot_pair_drift`	P2 (DOT registry)
`signature_failure`	P2 (DOT registry)

Open schema gap:

Umbrella vs separate families — Đ44 must decide: one family with event_kind sub-type discriminator, OR one family per sub-kind. Recommendation: umbrella for envelope consistency; sub-kind specialization via JSONB findings.
wrong_audience_result_event MUST carry HIGH risk class first-class (G5 group), not via findings JSONB — security event class needs first-class queryability.
Owner field shape (text vs FK to Đ37 role table) — cross-link Đ37.

Recommended registry status:

status: proposed_for_dieu44_ratification
maturity_proposed: M1 (defined; sub-kinds at varied maturity)
top_level_or_sub_class: top-level umbrella with event_kind sub-class discriminator (recommended)
joint_ratification_with: none (governance_event is its own family family)

5.6 `semantic_thread` ⚠️ (P2 — deferred from P0)

Purpose: Living domain/topic axis — connects IUs across documents, object types, and time. Higher-order construct containing memberships, evidence, signals, expected chain.

Source deliverables:

D9 §4.1, §4.2 — Thread definition + object family.
D11 §4.2, §4.4 — Thread retrieval consumer.

Related P0 item: NONE. semantic_thread is P2; not required for P0 migration design.

P0 required? NO. semantic_thread is proposed here so Đ44 governance has the full picture, but its ratification can be deferred to a later Đ44 phase aligned with P2 schema design.

Owner law / compatibility target:

Primary: Đ44 / UOSL.
Cross-law: Đ39 (universal_edges-first rule; thread_membership prefers universal_edges extension), Đ24 (thread vocabulary), Đ37 (Threading Domain Owner per G-1).

OQC check:

OQC field	Maps to semantic_thread
identity	thread_id
version	thread_version (split/merge tracking)
provenance	created_by, created_at, lineage (predecessor threads on split/merge)
classification	thread_kind (domain axis vs lifecycle axis vs other)
governance state	health_status, owner (Đ37 Threading Domain Owner per G-1), maturity

OQC check: PASS.

G1–G12 mapping summary:

Group	Field hint
G1 (identity)	thread_id
G2 (classification)	thread_kind, classification_labels
G3 (relations)	(memberships via universal_edges first per Đ39; predecessor lineage on split/merge)
G4 (publication)	(threads aren't published as IUs; thread context packs are derived views)
G5 (governance state)	health_status, owner, maturity, last_activity_at
G6 (semantics)	purpose, expected_chain (JSONB)
G7 (provenance)	created_by, created_at, lineage

Open schema gap:

semantic_thread_membership — Đ39 universal_edges first; Đ44 must confirm reuse pattern (edge_kind='thread_member' with status/confidence/evidence payload extensions) before approving separate membership table.
Expected lifecycle chain JSONB shape.
Negative knowledge persistence — separate sub-family vs part of governance_event.

Recommended registry status:

status: proposed_for_dieu44_ratification_at_p2_phase
maturity_proposed: M0 (concept; awaiting operational pilot)
top_level_or_sub_class: top-level (semantic_thread is conceptually distinct from manifest/cut/verify/governance families)
ratification_phase: PARALLEL to P2 schema design phase, NOT blocking P0

6. Family Ratification Order

Recommended order for Đ44 governance to ratify:

Step 1 (joint, P0-blocking):
  - manifest_envelope
  - manifest_unit_block
  (joint ratification because they share composite identity pattern)

Step 2 (joint, P0-blocking):
  - cut_change_set
  - verify_result
  (joint because they share DOT-pair signature schema)

Step 3 (P0-blocking):
  - governance_event (umbrella with event_kind discriminator)

Step 4 (P2; deferred):
  - semantic_thread

Steps 1–3 are P0-blocking and must close before P0 Migration Design phase. Step 4 is parallel to P2 schema design (later).

7. Open Schema Gaps Across Families (consolidated)

These are gaps that surface across multiple families and need Đ44 cross-family decisions:

OQC composite identity pattern — manifest_unit_block uses composite identity (envelope_id + unit_local_id); Đ44 must confirm OQC accepts composite.
DOT-pair dual signature schema — shared by cut_change_set and verify_result; one canonical signature record vs duplicated columns.
JSONB acceptance for G5/G6 group fields — findings, evidence_bundle, expected_chain all proposed as JSONB; Đ44 must confirm JSONB is acceptable for governance-state and semantics groups.
Umbrella family vs separate families — governance_event proposed as umbrella with event_kind sub-class; Đ44 may prefer separate families for some sub-kinds (especially wrong_audience_result_event due to HIGH-risk class).
First-class column vs profile JSON — many G6 semantics fields (semantic_role, edge_readiness_notes, candidate_edges) could live in either; Đ44 must publish the policy.
Maturity ladder semantics — proposed M0/M1/M2 hints per family; Đ44 must confirm what each level operationally means (cross-link D7 §4.7 open question 3).

8. Cross-Law Coordination

Đ44 ratification of these families requires cross-law signatures / dependencies:

Family	Đ24	Đ32	Đ37	Đ38	Đ39	Đ0-G
manifest_envelope	required (header vocab)	required (risk_class enum)	required (role mapping for emitted_by)	required (manifest-as-code authority)	—	check (birth gate readiness flag)
manifest_unit_block	required (section_type/unit_kind/body_source_policy/etc.)	required (length_flag/review_flags severity)	—	required	required (candidate_edges → universal_edges)	required (birth_gate_class field)
cut_change_set	—	required (rollback risk)	required (DOT-pair signing per G-4)	required	—	—
verify_result	—	required (verify failure risk)	required (NEEDS_HUMAN escalation via Đ37 queue)	required	—	check (axis-2 advisory paths)
governance_event	required (event_kind vocab)	required (risk_class per sub-kind; HIGH for wrong_audience_result)	required (owner field; routing channels)	required	—	—
semantic_thread	required (thread_kind vocab)	required (HIGH-risk for legal/governance/code-impact threads)	required (G-1 Threading Domain Owner)	—	required (universal_edges-first)	—

Đ24 vocabulary closures (parallel package) are MANDATORY before any Đ44 family with required (Đ24) cross-law can be ratified.

9. Status

package_status: PROPOSED_FOR_DIEU44_RATIFICATION
families_proposed: 6
families_p0_blocking: 5 (manifest_envelope, manifest_unit_block, cut_change_set, verify_result, governance_event)
families_p2_deferred: 1 (semantic_thread)
oqc_check_pass_count: 6 of 6
g1_g12_mapping_drafted: 6 of 6 (gaps recorded where applicable)
open_cross_family_gaps_recorded: 6 (§7)
cross_law_dependencies_mapped: 6 families × multiple laws (§8)
dieu44_status_marker: CONTROLLED_DRAFT (compatibility target; not enacted)
no_schema_created: true
no_ddl_written: true
no_sql_written: true
no_pg_mutation: true
no_qdrant_mutation: true
no_p0_migration_design_started: true
no_implementation: true
parallel_dieu24_closure_required: true
implementation_planning_allowed: false
implementation_allowed: false
migration_design_allowed: not_yet_pending_dieu44_ratification_AND_dieu24_closure_AND_p0_migration_design_prompt_approval

10. Coverage Check (mandatory sections from prompt)

Required content	Where addressed
List all Family Registry candidates required before P0 Migration Design	§4 + §5
For each family: purpose, source deliverable, related P0 item	§5.1–§5.6
For each family: owner law / compatibility target	§5.1–§5.6
For each family: OQC check	§5.1–§5.6
For each family: G1–G12 mapping summary	§5.1–§5.6
For each family: required for P0 or later P2/P3	§5.1–§5.6 + §4 summary table
For each family: open schema gap	§5.1–§5.6 + §7 consolidated
For each family: recommended registry status	§5.1–§5.6
Đ44 controlled draft / compatibility target statement	§2
No schema, no DDL, no PG mutation	§1, §2, §9

dot-iu-cutter v0.1 — Đ44 Family Registry Closure Package

1. Hard Boundaries

2. Đ44 / UOSL Status Statement (binding)

3. Purpose

4. Family Registry Candidates Summary Table

5. Family Candidates — Detailed

5.1 manifest_envelope

5.2 manifest_unit_block

5.3 cut_change_set

5.4 verify_result

5.5 governance_event (umbrella family)

5.6 semantic_thread ⚠️ (P2 — deferred from P0)

6. Family Ratification Order

7. Open Schema Gaps Across Families (consolidated)

8. Cross-Law Coordination

9. Status

10. Coverage Check (mandatory sections from prompt)

5.1 `manifest_envelope`

5.2 `manifest_unit_block`

5.3 `cut_change_set`

5.4 `verify_result`

5.5 `governance_event` (umbrella family)

5.6 `semantic_thread` ⚠️ (P2 — deferred from P0)