03 — Điều 37 Ownership Interpretation + Candidate Owners
03 — Điều 37 Ownership Interpretation (Branch C)
Source: enacted knowledge/dev/laws/dieu37-governance-organization-law.md v3.3 (BAN HÀNH, Council THÔNG QUA Gemini 9.0/9.5 + GPT 7.9). Cross-checked against live PG.
1. What Điều 37 actually governs
The top-down governance axis (Luật → Cơ quan → Thực thể) built to mirror the existing bottom-up axis (Thực thể → Khai sinh → Phân loại) so that "when the two axes meet through every intermediate layer, nothing slips through." Everything answerable by one PG query (the 11-question table: how many laws, what domain each governs, gaps, overlaps, self-mirror laws with 0 DOT, orphan DOTs/collections, broken relations).
2. System-organization model (the 5-tier stack)
TẦNG 1 LUẬT (normative_registry) → TẦNG 2 PHẠM VI (law_jurisdiction) → TẦNG 3 CƠ QUAN (governance_registry) → TẦNG 4 LIÊN KẾT (governance_relations) → TẦNG 5 THỰC THI (law_dot_enforcement). Agency type ∈ {collection, dot, factory}; a factory agency ("Mother") has output_target ∈ {user, system, assembly}.
3. SSOT / reference rules
- Principle 9 (★F6): "KB = context. PG = operational. Lệch → system_issues." PG is the operational SSOT.
- Law SSOT =
normative_registry(Đ38 merged old law_registry → read-only view). All FKs (relations, jurisdiction, enforcement) point tonormative_registry.code. - Ownership is recorded in:
governance_registry.governing_law+.primary_collection+.domain,law_jurisdictionrows,law_dot_enforcementrows, andgovernance_relationsrows withrelation_type='owner'.
4. Relationship to governance_registry
Đ37 §5 mandates governance_registry (TẦNG 3), governance_relations (TẦNG 4), governance_audit_log (§5.5), law_jurisdiction (TẦNG 2). It defines the columns/CHECKs. NOTE — live drift: enacted §5.2 says type(collection/dot/factory) + governing_law + relation_type∈(owner/depends_on/cooperates/enforces/produces/consumes) + enforcement_role∈(primary/audit/support); the LIVE tables use gov_type(council/system/factory) + created_by_law + relation_type∈(owner/approver_tbox/executor_abox) + enforcement_role∈(executor/auditor) + a capability JSON not in the law. This is a LAW↔SCHEMA drift (doc 14 patch P-DRIFT).
5. No-double-ownership principle (verbatim)
§4.12 (★S178 Fix 24): "Một nội dung chuyên môn chỉ được MỘT luật quản lý." + Principle 8 (★F4): "1 DOMAIN MAX 1 PRIMARY — PG trigger chặn 2 luật primary cùng domain" (Trigger #3 trg_jurisdiction_one_primary_per_domain). Overlap is detected (DOT-GOV-CONFLICT §6 + MTX-LAW-OVERLAP §7) and resolved by a 6-step transfer with the result minuted to governance_audit_log.
6. No-orphan-governance principle (verbatim)
§1 glossary: "Mồ côi Điều 37 = Cơ quan thiếu liên kết cần thiết (top-down)." + "Khoảng trống (Gap) = Domain/collection không thuộc phạm vi luật nào." Principle 4: "MỌI CƠ QUAN CÓ MÃ … Sinh ra = đăng ký. Không đăng ký = mồ côi." Enforced by DOT-GOV-VERIFY (daily) + DOT-GOV-DISCOVERY (weekly) → MTX-GOV-TOPOLOGY.
7. How a cross-system capability (grouping/classification) should be owned
§4.12 criterion (d), verbatim: "hòa → Hội đồng quyết + ghi biên bản vào governance_audit_log." When ownership cannot be resolved by the 3 substantive criteria (owns the CONCEPT / owns the LIFECYCLE-POLICY / owns the canonical PG TABLE), the Council decides and the decision is minuted to governance_audit_log. Council is the assignor of last resort, not a default catch-all; the assigned owner must then be equipped per §4.13 (PG table + DOT + health check). Precedent (G1 decision): tier_registry → GOV-COUNCIL only (no Mother claims it) — Council can hold a registry directly when no Mother fits.
8. Which existing owner should own it — live evidence
classificationdomain → law-owned (Đ24 primary, Đ29 secondary) ✅ but agency-orphaned ❌.pivotdomain → law-owned (Đ26 primary) ✅ but agency-orphaned ❌.- grouping / threshold / pin / phantom → no domain and no law ❌❌.
So the cross-system capability is partly already centralized (law layer) and entirely un-owned at the agency layer.
9. Is a new owner forbidden, unnecessary, or approval-gated?
Approval-gated, DOT-mediated, Council-reviewed — not free, not forbidden. New agencies are created via DOT-GOV-ONBOARD (B-tier); manual writes blocked by 8 PG triggers (§12), "CẤM --admin". Per Đ32, any system-impacting change is APR-gated; amend_law is RESERVED (handler unimplemented → DB gate blocks). Reuse-first (Đ7) says: do not mint a new agency until reuse proves absence. Here reuse does NOT prove absence — GOV-COUNCIL and GOV-SIV can hold these domains. ⇒ a new GOV agency is unnecessary for now.
10. Does Đ37 give enough structure to govern the Registries-Pivot concerns?
| Concern | Enough structure in Đ37? |
|---|---|
| grouping policy | Partial — needs an agency owner assigned to classification; the structure (domain+jurisdiction+relations) exists |
| classification | Yes (Đ24/Đ29 law) + needs agency owner |
| label/taxonomy | Yes (Đ24, domain classification.label exists) + needs agency owner |
| pin/watch | No — no domain, no law (LAW_GAP + DOMAIN_GAP) |
| phantom definition | No — LAW_DEFINITION_GAP (Đ37 can assign owner once a law defines it) |
| pivot coverage | Yes (Đ26, domain pivot) + needs agency owner |
| DOT grouping action | Yes — Đ35 paired-DOT model fully covers it |
| Registries-Pivot route/API | Yes — Đ28 template registry; API-exception needs Đ41 approval |
Candidate owner options (pros/cons/fit/risk)
GOV-COUNCIL — own classification/grouping/taxonomy POLICY
- Pros: cross-system taxonomy is exactly its remit (domain=governance); §4.12(d) makes it the natural assignor; G1 precedent (
tier_registry→GOV-COUNCIL); no new agency. Cons: Council is a deliberative body, not an operational executor — needs DOT + health agency beneath it. Law fit: high. Fragmentation risk: lowest. Recommendation: YES for the policy/definition layer.
GOV-SIV — own integrity/health (count-integrity/orphan/phantom-detect/pivot-coverage)
- Pros: Registries-Pivot IS a verification surface; GOV-SIV owns monitoring.integrity (Đ31), already enforced by 22 DOTs; raises system_issues natively. Cons: does not own taxonomy policy (that's classification). Law fit: high for health, not for policy. Risk: low. Recommendation: YES for the health/execution layer.
GOV-MOW — workflow/display grouping
- Pros: owns workflows (assembly.workflow). Cons: grouping is not a workflow output;
must_not_ownfor MOW excludes information_unit; mother still draft. Law fit: low. Risk: would mis-scope grouping as a workflow. Recommendation: NO.
GOV-MOIT — metadata/input/form classification
- Pros: "Mother of Input Templates" handles input_form/field metadata. Cons: classification of EXISTING entities ≠ input-form metadata; must_not_own excludes workflows/tasks/templates; draft. Law fit: low-medium. Risk: conflates form-metadata with system taxonomy. Recommendation: NO (it owns input metadata, not classification of the whole system).
GOV-MOUT — Registries-Pivot render templates
- Pros: Mother of UI/Output Templates owns
design_templates(Đ28). Cons: owns rendering only, not the data/grouping. Law fit: high for the route/template object only. Recommendation: YES, scoped to the render template.
New GOV agency (e.g. GOV-CLASS)
- Only if reuse-first proves absence — it does not (Council+SIV cover it). Approval-gated (Đ32 high → president+2 ai_council). Recommendation: DEFER/REJECT unless Council explicitly delegates an operational classification body later.
Net recommendation (carried to doc 12): split by object type — POLICY→GOV-COUNCIL, HEALTH→GOV-SIV, DOT-exec→GOV-DOT, render→GOV-MOUT — assigned via the Đ37 §4.12(d) Council-decision + governance_audit_log minute, with the classification and pivot domains attached to their agency owner (INSERT/UPDATE governance_registry + governance_relations, approval-gated). No new agency.