KB-7F0C

12 — Decision Options & Recommendation

6 min read Revision 1
decisiongovernance-ownerrecommendationregistries-pivotbranch-l

12 — Decision Options & Recommendation (Branch L)

The decision: who owns system-wide classification / grouping / pivot-coverage / pin / phantom, and via what approval path? Evidence: classification domain is law-owned (Đ24/Đ29) but agency-orphaned; pivot domain is law-owned (Đ26) but agency-orphaned; grouping/threshold/pin/phantom have no law/domain; the approval spine (Đ32) and DOT model (Đ35) are complete and reusable; no per-table gov columns exist anywhere.

Option 1 — GOV-COUNCIL owns ALL system classification/grouping

  • Pros: single cross-system taxonomy owner; matches Đ37 §4.12(d) (Council = cross-cutting assignor) + G1 precedent (tier_registry→GOV-COUNCIL); no new agency; lowest fragmentation.
  • Cons: Council is deliberative, not an operational executor; it cannot run scanners/health itself → would still need GOV-SIV/GOV-DOT beneath it; risk of Council becoming a bottleneck for routine low-risk label changes.
  • Law fit: high. Impl burden: low (assign domain, no new code). Risk: medium (operational bottleneck).

Option 2 — GOV-MOIT owns metadata/classification

  • Pros: a factory mother for input/form metadata exists.
  • Cons: GOV-MOIT governs input_form/field metadata, NOT classification of existing system entities; its must_not_own excludes workflows/tasks/templates; still draft; would mis-scope grouping as form metadata.
  • Law fit: low-medium. Impl burden: medium (activate mother + redefine scope). Risk: high (scope creep / wrong mental model).

Option 3 — GOV-MOW owns workflow/display grouping

  • Pros: owns workflow assembly.
  • Cons: grouping is not a workflow output; must_not_own excludes information_unit; draft.
  • Law fit: low. Impl burden: medium. Risk: high (category error).

Assign each layer to the existing agency that already owns the adjacent law:

  • Policy/definition (classification, grouping, threshold, label dimensions, phantom definition, pin policy) → GOV-COUNCIL (law Đ24/Đ29; §4.12(d) assign).
  • Health/verification (count-integrity, orphan, phantom detection, pivot coverage) → GOV-SIV (law Đ31; already 22 enforcing DOTs).
  • Execution (grouping/pivot scan-propose-apply-audit DOTs) → GOV-DOT (law Đ35; paired model).
  • Render (Registries-Pivot route/template/API) → GOV-MOUT (law Đ28; + Đ41 API exception).
  • Pros: every layer owned by the agency that already owns its law → maximal reuse, zero category errors, no new agency, clean separation of powers (matches Đ23 "1 làm / 1 kiểm / 1 giám"); approval routed by risk via Đ32; lowest island risk.
  • Cons: ownership spans 4 agencies → needs a clear authority map (this doc) so changes route correctly; slightly more coordination than a single owner.
  • Law fit: highest (each owner = its own law). Impl burden: low-medium (assign domains + a few governance_relations edges + enact 2 law clauses). Risk: low.

Option 5 — Create a new owner (GOV-CLASS)

  • Only if reuse-first proves absence — it does NOT (Council+SIV+DOT+MOUT cover every layer). Đ37: new agency = approval-gated (Đ32 high → president + ≥2 ai_council), DOT-onboarded, council-reviewed.
  • Pros: a single operational classification body could reduce Council load later.
  • Cons: violates reuse-first (Đ7) now; adds a governance node to maintain; premature.
  • Law fit: allowed but unjustified. Impl burden: high. Risk: medium (governance sprawl — the very thing the mission warns against).

RECOMMENDATION — Option 4 (split by object type), opinionated

Adopt Option 4. It is the only option where every concern is owned by the agency that already owns the governing law, which is exactly how Đ37 intends ownership to flow (law → agency → entity). It reuses 100% of the central spine (Đ24/26/28/31/32/35/45), creates no new agency, no local approval, no per-table gov columns, and produces a clean authority map:

Concern Owner (agency) Governing law Approval path Executor
Classification / grouping / threshold / label dimension GOV-COUNCIL Đ24 (+Đ29) Đ32: rule_change/schema_add (med→president; structural→council_review) GOV-DOT
Phantom definition GOV-COUNCIL Đ31 clause (P1) council_review GOV-SIV detect
Pin policy (global) GOV-COUNCIL new clause (P-PIN) Đ32 schema_add GOV-DOT
Count-integrity / orphan / phantom-detect / pivot-coverage health GOV-SIV Đ31 (+Đ19/26) n/a detect; act=Đ32 GOV-DOT
Pivot definitions / coverage repair GOV-SIV authority, exec GOV-DOT Đ26 Đ32: new_dot/schema_add GOV-DOT (dot-pivot-declare↔health)
Grouping/pivot DOTs GOV-DOT Đ35 apply=Đ32; scan/audit=auto self
RP route / template / API GOV-MOUT Đ28 (+Đ41) route=RG8; API=Đ41 exception template DOTs

Mechanism (all approval-gated, none executed by this audit):

  1. Council resolves ownership via Đ37 §4.12(d) and minutes it to governance_audit_log.
  2. Attach domains: classification & classification.label/.species → GOV-COUNCIL; pivot → GOV-SIV — by INSERT/UPDATE governance_registry + governance_relations agency→law edges (Đ32 schema_add/rule_change, council).
  3. Enact law clauses P1 (phantom), P2 (threshold), and P-PIN (pins) via council_review.
  4. Register new issue/event types (Đ45) approval-gated.
  5. Author grouping/pivot DOTs under Đ35 (paired, approval-gated).

Do NOT: mint GOV-CLASS now; add owner_gov_code columns to policy tables; let Registries-Pivot "own" any of this; self-approve any of the above.

Back to Knowledge Hub knowledge/dev/reports/architecture/full-stack-governance-alignment-audit-registries-pivot-grouping-2026-05-31/12-decision-options-and-recommendation.md