dot-iu-cutter v0.1 — Governance Closure Package

Date: 2026-05-15 Status: PLANNING — pending Đ37 closure Trigger: User PASS_DESIGN_WITH_NOTES Baseline: rev5d + 11 design deliverables + 4 Gate reviews Scope: GOVERNANCE PLANNING ONLY. No code, no DDL, no migration, no PG mutation, no UI build, no implementation planning detail.

1. Purpose

Đóng 5 governance gaps đã được Gate 1 / D10 / Decision Backlog (D5) xác định, để hệ thống dot-iu-cutter v0.1 có owner / reviewer / signing authority hợp lệ theo Đ37 trước khi bước vào P0 schema migration design và sau đó là implementation planning.

Package này không tạo role mới ngoài Đ37, không tạo notification system song song, không invent governance vocabulary. Mọi closure phải route qua kênh Đ37 hiện hữu (criterion 38).

2. Scope

5 governance gaps với decision needed + owner proposal + affected deliverables + risk + closure path + escalation level.
Closure sequencing recommendation.
Đ37 closure prerequisites checklist.

Out of scope: chi tiết quy trình nội bộ Đ37 (do Đ37 governance quyết); chi tiết schema (xem P0 Schema Planning Package); user policy decisions (xem User Decision Pack).

3. Hard Boundaries

no_code: true
no_ddl: true
no_migration: true
no_pg_mutation: true
no_qdrant_change: true
no_ui_build: true
no_implementation_dispatch: true
no_new_governance_role_outside_dieu37: true
no_parallel_notification_system: true
no_silent_vocabulary_invention: true

4. Closure Tracking Envelope

Mỗi gap được track qua Decision Backlog Registry (D5) như một entry kind='escalation' hoặc kind='decision'. Khi closure xong, entry chuyển status='resolved'. Trước đó:

backlog_entry_status: open
closure_phase: governance_closure
implementation_unblock_dependency: true

5. The 5 Governance Gaps

5.1 Gap G-1 — Threading Roles

Source: D9 §4.10 (mapping mismatch), D10 §7 (governance gap #1), Gate 3 review (PASS_WITH_NOTES).

Decision needed:

Who owns a semantic_thread lifecycle (creation, supersession, split/merge)?
Who reviews semantic_thread_candidate membership before acceptance?
Who arbitrates user_ai_disagreement events?
Who oversees overbroad / too_narrow / stale thread health signals?

Proposed owner role mapping (within Đ37):

Threading concern	Proposed Đ37 role
Thread owner (per thread)	Domain Owner (Đ37 SOP role) — appointed per domain
Membership reviewer	AI Council reviewer (default) escalating to Human reviewer for risk/contested
Thread split/merge governance	Council
User-AI disagreement arbitration	Human reviewer per Đ37 escalation queue
Anomaly oversight (overbroad/too_narrow/stale)	Registry custodian (see G-2) + Council

Affected deliverables: D9, D11, D3, D5.

Risk if unresolved:

Ungoverned thread creation → uncontrolled growth of semantic graph.
Auto-accept may run without policy-approved reviewer chain → violates Đ32 risk gating.
user_ai_disagreement events have no arbitration channel → silent overrides possible.
Cross-domain threads end up orphaned without an owner.

Recommended closure path:

Đ37 governance assigns Domain Owner role per starter domain (e.g., birth_gate, segmentation, threading, retrieval, audience-scope).
Đ37 defines escalation path: AI Council → Human reviewer → Council for contested.
Decision Backlog entry resolved when role assignments are recorded as Đ37 entries.

User/Council decision required: YES (Council assignment is Đ37 council scope; User confirms Domain Owner appointments).

5.2 Gap G-2 — Decision Backlog Custodian

Source: D5 §4.4 (sweep cadence), D5 §4.10 (closure criteria), D10 §7 (#2).

Decision needed:

Who runs the registry sweep (Section D5 §4.4 — every governance review / health report / Self-Review)?
Who has authority to close entries (resolved / superseded / deferred)?
Who is responsible for re-surfacing next_review_date expirations?

Proposed owner role mapping:

Custodian concern	Proposed Đ37 role
Sweep execution	Registry custodian (Đ37 SOP role, governance ops)
Entry closure (low/standard risk)	AI Council, with human reviewer co-sign for standard
Entry closure (high risk)	Đ32 full approval + Council sign-off
Next_review_date re-surfacing	Automated by sweep (Registry custodian responsible)
Markdown mirror regeneration	Registry custodian

Affected deliverables: D5 (primary), D1, D3, D4, D9, D11 (all producers).

Risk if unresolved:

"Anti-forgetting" guarantee (D5 §4.11) cannot be enforced without a sweep owner.
Decisions silently stale; next_review_date expirations ignored.
Markdown mirror drifts from PG SSOT → governance trust loss.
Producers cannot route entries reliably.

Recommended closure path:

Đ37 designates Registry custodian role (likely existing governance ops function).
Đ37 publishes sweep cadence defaults (cross-link with User Decision Pack §3 if cadence requires User confirmation).
Decision Backlog entry resolved when custodian is named and first sweep scheduled.

User/Council decision required: Council (Đ37 council scope). User confirms cadence defaults via User Decision Pack.

5.3 Gap G-3 — Capability-Intake Reviewer

Source: D4 §4.5 (capability acceptance authority), D10 §7 (#3), Gate 2/Gate 4 review (closure needed).

Decision needed:

Who reviews capability_intake_record for TAC capability changes (Đ38 surface)?
Who reviews KG capability changes (Đ39 surface)?
Who reviews policy / threshold tuning intakes (Đ24 / Đ32 boundary changes)?
Who reviews tool revision upgrades (cutter / verifier)?

Proposed owner role mapping:

Intake kind	Proposed Đ37 role / approval level
tac_capability (Đ38)	TAC governance reviewer + Council for Standard+ risk
kg_capability (Đ39)	KG governance reviewer + Council for Standard+ risk
policy / threshold tuning	Council (always Standard risk minimum per D4 §4.5)
Đ24 vocabulary change	Đ24 governance (cross-law)
tool_revision	Council + Đ32 review (always Standard risk minimum)
Audience filter policy	Council + Access-Control Authority (G-5)

Affected deliverables: D4 (primary), D1 (tool revision), D6 (axis-2 advisory→hard promotion), D9, D11.

Risk if unresolved:

Capability intakes accumulate as proposed without review owner → cutter becomes stale (D4 §4.9 anti-stale rule fires but routing breaks).
Positive recursion loop (P10) cannot close.
Tool revisions could deploy without Đ32 risk approval → Đ32 violation.
Đ24 vocabulary changes risk silent invention.

Recommended closure path:

Đ37 assigns TAC / KG governance reviewer roles (may map to existing Đ38 / Đ39 owners).
Council formally takes ownership of policy / threshold / tool-revision intakes.
Đ24 cross-law channel formalized for vocabulary intakes.
Decision Backlog entry resolved when all four reviewer mappings are recorded in Đ37.

User/Council decision required: Council. User confirms Self-Review cadence + thresholds via User Decision Pack §8.

5.4 Gap G-4 — DOT-Pair Signing Authority

Source: D1 §4.14 (DOT-pair definition), Gate 2 §3.6 (boundary clarification needed), D10 §7 (#4), criterion 28.

Decision needed:

Who is the authority that registers dot-iu-cutter (executor) and dot-iu-cutter-verify (verifier) as a valid pair?
Who authorizes their joint signing key / signature record on REPORT envelopes?
What is the boundary between executor's internal VERIFY precheck and verifier's final co-sign (Gate 2 closure)?
Who can rotate / revoke the pair if compromised or upgraded (cross-link with G-3 tool_revision)?

Proposed owner role mapping:

DOT-pair concern	Proposed Đ37 role
Pair registration	DOT registry custodian (existing Đ37 SOP role from S178 A+3 paired-DOT pattern)
Joint signature authority	DOT registry custodian + Council ratification
Executor vs Verifier boundary policy	Council via D4 capability intake (G-3)
Pair rotation / revocation	DOT registry custodian + Đ32 risk approval if mid-cycle

Affected deliverables: D1 (primary), D4 (tool revision propagation), D8 (missing instrumentation: DOT-pair signature recording).

Risk if unresolved:

REPORT cannot emit valid PASS (criterion 28 fails) — both signatures required.
If only executor signs → DOT-pair guarantee broken.
Tool revision drift between executor and verifier silently allowed → invalid co-sign.
Cross-link with S178 A+3 pattern lost — existing DOT registry pattern not honored.

Recommended closure path:

Đ37 confirms DOT registry custodian role (likely existing from S178 A+3).
Council ratifies joint signature schema (no DDL written in this package; schema enters P0 §6 backlog).
Boundary policy decided as a D4 intake item (cross-link).
Pair rotation policy aligned with G-3 tool_revision review.
Decision Backlog entry resolved when custodian named + boundary policy decided.

User/Council decision required: Council. User confirms tool revision cadence indirectly via cross-link with User Decision Pack §8 (Self-Review cadence).

5.5 Gap G-5 — Audience-Scope Access-Control Authority

Source: D11 §4.10 (access-control guardrail), rev5d §14.2, D10 §7 (#5), Gate 3 §3.7.

Decision needed:

Who owns the policy that defines audience classes (AI/Agent, Employee, Partner, Customer)?
Who reviews / approves new audience filter rules?
Who handles wrong_audience_result events (security/governance, NOT search-quality)?
Who maintains visibility / readiness / publication_state vocabulary (cross-link Đ24)?
Who has authority to block / unblock retrieval responses on access-control grounds?

Proposed owner role mapping:

Access-control concern	Proposed Đ37 role
Audience class definition	Access-Control Authority (Đ37 SOP role; may map to existing security/governance lead)
Filter policy approval	Access-Control Authority + Council for Standard+ risk
`wrong_audience_result` security event handling	Access-Control Authority + Đ32 full escalation (high-risk path)
Visibility/readiness/publication vocabulary	Đ24 governance (cross-law)
Response block/unblock authority	Access-Control Authority

Affected deliverables: D11 (primary), D3 (security-class signal handling), D7 (G5 governance state fields), D10 (legal alignment).

Risk if unresolved:

Audience-scoped search becomes a quality filter, not access control → rev5d §14.2 guardrail violated.
wrong_audience_result events have no security owner → potential information leakage.
Customer/partner-facing surfaces (out of v0.1 scope but with hooks) lack policy authority.
v0.1 metadata hooks (visibility/readiness/publication) accumulate without governance.

Recommended closure path:

Đ37 designates Access-Control Authority role.
Authority + Đ24 + Council ratify audience class vocabulary.
Authority publishes wrong_audience_result runbook (Đ32 escalation path).
Decision Backlog entry resolved when authority named + audience vocabulary recorded.
Cross-link with User Decision Pack §3 (audience definitions) and §6 (wrong_audience_result handling).

User/Council decision required: Council + User. User must confirm audience definitions and handling policy via User Decision Pack §3 and §6.

6. Recommended Closure Order

G-2 (Backlog custodian)          # closure infrastructure first
   ↓
G-1 (Threading roles)            # core governance owners
G-5 (Access-Control Authority)   # security-class owner
   ↓
G-3 (Capability-intake reviewer) # depends on G-1, G-2 routing
G-4 (DOT-pair signing authority) # depends on G-3 tool_revision policy

Rationale:

G-2 first — without a custodian, no other gap can be tracked to resolution.
G-1 and G-5 in parallel — both are foundational owners; can be assigned independently.
G-3 depends on G-1/G-2 — intake routing needs governance roles + custodian.
G-4 depends on G-3 — tool revision policy (G-3) defines DOT-pair rotation rules.

7. Cross-Links

Gap	Cross-links into
G-1 Threading roles	User Decision §1 (auto-accept thresholds); P0 Schema §5 (decision_backlog_entry); D9, D11
G-2 Backlog custodian	User Decision §4 (backlog scope); P0 Schema §5; D5
G-3 Capability-intake reviewer	User Decision §8 (Self-Review cadence); D4
G-4 DOT-pair signing	G-3 tool revision; D1; D8 missing instrumentation #8
G-5 Access-Control Authority	User Decision §3 (audience defs), §6 (wrong_audience handling); D11; D7 G5 fields

8. Đ37 Closure Prerequisites Checklist

Before any single gap can be marked resolved:

Đ37 role assignment recorded (no parallel role created).
Backlog entry exists in D5 with full envelope (decision_id, summary, risk class, owner, related_law_or_design).
Closure rationale recorded (D5 §4.10 closure criteria).
Affected deliverable refs cross-linked.
Health signal hook (if applicable) routed (D3).
No new notification system created (criterion 38).

9. Open Questions Routed to Đ37

Items needing Đ37 governance input not resolvable within this package:

Does Đ37 already have a Domain Owner role per domain, or do we need a new SOP entry?
Is the Registry custodian an existing governance-ops role or a new SOP role?
Does DOT registry custodian from S178 A+3 cover dot-iu-cutter pair, or new entry needed?
Does an Access-Control Authority exist in current Đ37, or is it a new role?
Cross-law Đ24 channel for audience/visibility/readiness vocabulary — formalized or ad-hoc?

These are Đ37 governance discovery questions, not design decisions.

10. Status Block

package_status: READY_FOR_DIEU37_REVIEW
closures_required: 5
closure_order_defined: true
user_decisions_cross_linked: 4 (threading, backlog scope, audience defs, wrong_audience handling)
council_decisions_required: 5 (all gaps need Council ratification at some step)
implementation_unblock_dependency: true
no_code: true
no_ddl: true
no_migration: true
no_pg_mutation: true
ready_for_implementation_planning: false

11. Coverage of Review Findings

Review source	Closure mapping
Gate 1 §4 closure #1 (Đ37 owner for 5 gaps)	This package, all 5 gaps
D10 §7 (5 governance gaps)	This package, all 5 gaps
Gate 4 §2.2 (Governance closure required)	This package, all 5 gaps + Family Registry cross-link
D5 §4.5 routing	Honored throughout
criterion 37, 38	Honored (Đ37 channels only, no parallel)