08 — Draft Law / Design Clauses for One-Roof Governance

Branch H. DRAFT TEXT ONLY. No enactment, no version bump, no status change, no normative_registry touch. Each clause is a proposal for a future, separately-ratified phase. The live engine itself blocks enactment via APR today (apr_action_types.amend_law / enact_nrm = handler_ref='unimplemented', Điều 32 §3.3/§7) — so these remain drafts by construction.

Anchoring: clause numbers below are proposed additions keyed to the verified current structure of each law (clause IDs confirmed live via KB read). Where a law is draft (Điều 36) or agency-orphaned (24/26/28/45) that is noted.

8.1 ĐIỀU 37 — Governance Organization (v3.3 enacted; owner: GOV-COUNCIL)

Current relevant structure: §4.12 SSOT no-overlap · §4.13 trang-bị-đủ-công-cụ · §4.14 tham-chiếu-liên-luật · §5.2 governance_registry · §5.4 governance_relations (CHECK source_type/target_type ∈ {law,agency}) · §12 PG triggers.

DRAFT §4.15 — Nguyên tắc Một Mái Nhà & Đối tượng Vô Chính Phủ (One-Roof & Anarchic Object).

(a) Mọi đối tượng được-quản-trị (governed object — định nghĩa tại §1 bổ sung) PHẢI có một đường sở hữu trung tâm hợp lệ trong mái nhà quản trị (governance_registry + governance_relations + law_jurisdiction), cùng các liên kết phê duyệt/kiểm toán/hoàn tác tương ứng với mức rủi ro. (b) Đối tượng được-quản-trị thiếu ≥1 liên kết bắt buộc = mồ côi quản trị (governance-orphan). Mồ côi quản trị rủi-ro-cao có khả năng thay đổi sự-thật/thực-thi/phân-loại/hiển-thị/tự-động-hóa/issue/cleanup mà không có chủ/duyệt/kiểm-toán/hoàn-tác = đối tượng vô chính phủ (anarchic object). (c) Cấm ốc đảo quản trị địa phương: không cơ chế nào được tự định nghĩa chủ sở hữu / phê duyệt / vòng đời / luật-lệ riêng ngoài mái nhà trung tâm. (d) Phát hiện mồ côi/vô-chính-phủ KHÔNG được phụ thuộc trí nhớ người/agent; PHẢI là một bất biến được tính tự động (Coverage Invariant, dưới Điều 31), giống cơ chế phát hiện mồ côi khai sinh (NV1).

DRAFT §4.16 — Owner-assignment protocol. Owner assignment to a governed object follows scan→propose→approve→apply→audit (Điều 35 lifecycle): the gap is detected (GOV-SIV), an assignment is proposed (approval_requests), approved per Điều 32 quorum (medium routine / high if it changes a law-owned domain), applied as a governance_relations edge, and audited to governance_audit_log. No owner is assigned by editing text or UI.

DRAFT §4.17 — Approved-exception protocol. A sanctioned bypass (e.g. a read-only Direct-PG adapter) is recorded as an approval_requests exception with a TTL and an overdue path (reuse Điều 35 §6.5 admin_fallback → fn_admin_fallback_overdue_scan()). An expired exception becomes a direct_pg_unratified_exception issue (critical). An exception is coverage, not an excuse to skip the roof.

DRAFT §4.18 — Future-feature coverage rule. No new production feature reaches production unless every governed object it introduces or touches satisfies GOVERNANCE_COVERAGE_PASS (Điều 31 invariant) or has an approved exception. New object types are covered by adding a source-inventory row (data, not code).

DRAFT §5.4-EXT — Object-ownership edges (structural, deferred). Extend governance_relations so an agency may own an object, not only a law: add target_type='object' with target_object_type + target_object_ref, OR introduce a sibling governance_object_ownership(owner_gov_code, object_type, object_ref, capability_code, law_ref, effective_from, effective_to). This is the one structural change One-Roof needs (today the §5.4 CHECK target_type ∈ {law,agency} makes object ownership inexpressible). Deferred to a Tier-3 design+approval phase — NOT part of this pack. Until then, ownership is resolved via law_jurisdiction.domain + inheritance (doc 04 §4.4).

8.2 ĐIỀU 31 — System Integrity (v1.2 enacted; owner: GOV-SIV)

Current structure: Nguyên tắc 1 (mọi lệch là lỗi) · 2 (phát hiện trước) · 6 (WATCHDOG) · §4.3 năm loại kiểm tra · §4.5 severity · §4.6 issue class · §4.8 coverage metrics (GATE/TARGET/HEALTH) · §VI DOT scanning under Đ31.

DRAFT §4.3-Loại6 — Governance-coverage check (kiểm tra thứ sáu).

Bổ sung loại kiểm tra thứ 6: Governance Coverage — với mỗi governed object, xác minh tồn tại đường sở hữu trung tâm hợp lệ + liên kết duyệt/kiểm-toán/hoàn-tác theo mức rủi ro. Thiếu = mồ côi quản trị (Điều 37 §4.15). Contract type gov_coverage (kề db_vs_db, dom_vs_contract). Đây là chiều "top-down governance" bổ sung cho orphan L1/L2/L3 (bottom-up) đã có.

DRAFT §4.6-ext — Issue classes. Add governance issue classes to §4.6: governance_orphan, local_governance_island, unratified_exception, alongside existing sync_fault/watchdog_fault. Severity computed per object-class × gap-type (doc 03 §3.3), honoring §4.5 (INFO = no issue).

DRAFT §4.8-ext — Coverage metric (GATE). Add Governance Coverage to §4.8 as a GATE for truth/authority-class objects: governance_orphans(truth-class)=0 is required before a feature is production-eligible (parallels the existing Page-Coverage GATE "Tier A 100%"). TARGET (soft) ≥ governed threshold for non-truth classes.

DRAFT §4.9-ext — WATCHDOG-of-coverage. The governance-coverage scanner is itself watched (Nguyên tắc 6): DOT-GOV-COVERAGE-AUDIT must report on cadence; silence ⇒ watchdog_fault critical. Scan cadence: truth/authority objects daily; full-population incremental per source (doc 11).

8.3 ĐIỀU 35 — DOT Governance (v5.2 FINAL enacted; owner: GOV-DOT)

Current structure: §3 two-tier A/B + paired_dot trigger · §6.2 fix_repair_dot 6-step · §6.4 verify 3 layers · §6.5 ADMIN fallback · §8 self-governing pairs.

DRAFT §6.2-bis — governance_coverage_dot lifecycle. Define a governance-coverage DOT family parallel to fix_repair_dot:

DETECT (tier A, read-only) → PROPOSE (tier B, writes approval_requests only) → APPROVE (Điều 32, risk from apr_action_types) → APPLY (tier B, paired, writes owner edge / exception) → VERIFY (tier A, orphan gone + no new orphan) → CLOSE (system_issues→resolved, APR→applied, vps_deploy_log entry). No coverage DOT may bypass DOT governance (must be in dot_tools, tiered, paired). Scan/detect/audit = automatic read-only; apply/assignment/exception = approval-gated.

DRAFT §3-note — pairing applies to coverage DOTs. The existing §3 trigger (DOT Cấp B PHẢI có paired_dot) governs the new DOTs unchanged — dot_authority_gap is therefore partly already enforced for DOTs (a tier-B DOT without paired_dot cannot be inserted). The new clause extends the concept to all governed code-executed objects, not just dot_tools rows.

DRAFT §6.5-note — exception reuse. The Điều 37 §4.17 approved-exception protocol reuses §6.5 admin_fallback_log + 24h retroactive-APR + fn_admin_fallback_overdue_scan() verbatim as its overdue mechanism (no new table).

8.4 ĐIỀU 24 / ĐIỀU 29 — Label, Taxonomy & Grouping (Điều 24 v1.3 enacted; agency-orphaned)

Current Điều 24: §5.1 taxonomy_facets (max_labels_per_entity, cardinality) · §5.2 anti-farming ceiling ("vượt threshold → ghi system_issues") · §5.4 scored-union grouping · label_rules (skip_wide_warning). Note: Điều 24 names no owning agency and has no governance_relations owner edge today.

DRAFT §0-OWNER (Điều 24 & 29) — central ownership. Classification, grouping, threshold, label-dimension, and pin policy are cross-system policy objects owned by GOV-COUNCIL (the policy/tie-break owner per GPT review). They are NOT owned by any single surface. A governance_relations owner edge GOV-COUNCIL → NRM-LAW-24 (and → NRM-LAW-29) is proposed (future apply) to close the current OWNER_GAP.

DRAFT §5.2-ext — grouping ceiling is a governed threshold. The "50 = MAX ungrouped ceiling, per-species" rule (Registries-Pivot design 07) is a threshold policy object: it lives in PG (a governed display_policy/threshold table with owner_gov_code='GOV-COUNCIL'), changed only via APR, NOT a literal in app code. max_ungrouped is a ceiling (≤50 CHECK), not a target. Relation to §5.2 anti-farming: both are governed thresholds emitting system_issues on breach — reuse the same emit, different facet.

DRAFT §5.4-note — grouping ⇒ classification ⇒ label. Grouping (Điều 26 L2 group list) is derived from classification (Điều 24 facets / label_rules), which is derived from species (Điều 36). One-Roof: a grouping policy that invents its own classification outside Điều 24's faceted SSOT is a classification_policy_unowned island. Grouping reuses taxonomy_facets/entity_labels/label_rules; it does not fork them.

8.5 ĐIỀU 26 — Pivot (v4.0 enacted; agency-orphaned)

Current: MT2 (đếm luôn đúng) · §II-QUATER 5-layer (L1/L2/L5 CỨNG) · §II-QUINQUIES max-7-dim · §0-AU (thêm dòng = INSERT không code) · §1C/1E (ma trận = pivot_definitions / DOT, không code).

DRAFT §0-OWNER (Điều 26) — pivot coverage as governed object. A pivot definition is a governed object (class pivot); its owner is the owner of its source collection (inheritance, Điều 37 §4.16/doc 04 §4.4). A pivot with no resolvable owner = pivot_coverage_unowned. Propose owner edge GOV-SIV → NRM-LAW-26 (health) + GOV-COUNCIL approver to close the law's OWNER_GAP.

DRAFT §MTx — PIVOT_MISSING is a system issue. When a required count has no pivot backing (the live RP "PIVOT_MISSING" state — grand-total/orphan/drift/coverage pivots absent), emit pivot_coverage_unowned (high) to system_issues (doc 07 #14). Counting truth with no pivot backing is a coverage failure, not a UI fallback. Grand-total must be a constant-bucket VIEW, never un-grouped count(*) (RP PIV-500 engine finding).

DRAFT §repair — pivot coverage repair governance. Repairing a missing pivot = INSERT pivot_definitions (Điều 26 §0-AU) via a governed DOT (Điều 35), approval-gated if it changes a counting contract. No hand-INSERT of pivot_definitions (Điều 26 §1E).

8.6 ĐIỀU 28 — Display / Nuxt boundary (v2.0 enacted; agency-orphaned, intended owner GOV-MOUT `draft`)

Current: §I "Nuxt CHỈ render từ khuôn đăng ký" · NT-D1 (no business logic in UI) · NT-D3 (config in PG) · Test-4 (100% Nuxt=PG) · §VIII whitelist/coverage 0-outside-registry.

DRAFT §0-OWNER (Điều 28) — render/display/API owner assignment. Render/display/API surface ownership belongs to GOV-MOUT (Mother of UI/Output Templates). Blocker (live): GOV-MOUT is status='draft' and was born under NRM-LAW-07, not NRM-LAW-28, and there is no owner edge to NRM-LAW-28. Propose (future apply): (a) activate GOV-MOUT (draft→active, Điều 32 high quorum) and (b) add owner edge GOV-MOUT → NRM-LAW-28. Until then, display/API is display_owner_gap (high) and the RP page is rendered under an UNRATIFIED_EXCEPTION.

DRAFT NT-D1-ext — no UI governance logic. Nuxt MUST NOT compute governance state (covered/orphan/island), count truth, or grouping truth. It renders the backend's v_governance_coverage_summary and pivot results only. The live violations (health.get.ts:123 totalGap=reduce(+Math.abs(gap)); index.vue hardcoded CAT-017/orphan_count:hd.totalGap) are retired (doc 09). Coverage = pivot-backed dimension, not frontend math (Test-4 100% Nuxt=PG).

DRAFT §VIII-ext — Direct-PG/API exception under governance. A render/API surface that reads PG directly (the live RP Nitro→read-only pg Pool, justified because Directus cannot serve PK-less views) is an approved_exception requiring: a law reference (Điều 33 §13 exception list), read-only enforcement, a TTL, and a vps_deploy_log ledger entry (today the RP adapter is un-ledgered — vps_deploy_log has 18 entries, all S178, none for registries-pivot).

8.7 ĐIỀU 45 — Event / Queue (v1.0 enacted; substrate-owned)

Current: §3.2/§6.4 register-before-emit · §4 signal-not-data + safe_payload CHECK · §6.6 event-vs-job · §6.7 9-state work_state_machine · §15.5 silent-gap.

DRAFT §3.2-note — governance gap event registration. The ~10 governance event_type rows (doc 07 §7.2) are registered via the Điều 35-style ratification before any emit. They satisfy §6.4 inclusion (DOT execution result / governance state change with owner + lifecycle), and explicitly fail telemetry exclusion (they are not metrics). They reuse the system domain for open/resolve and activate the dormant mother.governance.* shapes rather than fork new ones.

DRAFT §4-note — governance events are signals. Governance events carry governed_object_ref/gap_type/severity/coalesce_key only. No object body, no secrets (safe_payload CHECK). High-cardinality gap classes (e.g. mass coverage gaps) emit a summary event per scope/cycle, not one-per-orphan (§15.4 throttle), preventing an event_outbox flood.

DRAFT §6.6-note — detect vs remediate. Governance detection emits events; remediation (assignment apply) is a job with the 9-state machine (§6.7). The system must not assume "an event fired ⇒ the gap is fixed."

8.8 Cross-law consistency note (Điều 37 §4.14 compliance)

Each draft above declares its dependency (the law it amends) and references SSOT inline (Điều 37 §4.14 two-level rule). The One-Roof concept is anchored in Điều 37 (ownership) + Điều 31 (detection invariant) and referenced from 35/24/26/28/45 — it is not duplicated into each law (Điều 37 §4.12 SSOT no-overlap). Phantom definition (the LAW_DEFINITION_GAP) is assigned a home: defined by GOV-COUNCIL policy + detected under Điều 31, resolving the long-standing "phantom has no law" gap.

These drafts feed doc 10 phase 3 (ratification) and the doc-12 clause-drafting prompt. Nothing here is enacted.