07 — Pivot Governance Alignment (Branch G)

Sources: Đ26 Pivot/Counting Law v4.0 (knowledge/dev/laws/dieu26-pivot-law.md), live pivot_definitions (~37), pivot_results (126), law_jurisdiction (pivot→Đ26 primary), law_dot_enforcement (Đ26 = 8 DOTs).

1. Are pivot definitions governed objects?

Yes — by law. pivot_definitions is itself a registered registry (CAT-024); Đ26 §II-QUINQUIES 1D "Quản lý = pivot_definitions" and 1E "Thực hiện bằng DOT… KHÔNG INSERT tay" — pivots are created/changed ONLY via DOT, never by hand. pivot_count() is "PHƯƠNG THỨC ĐẾM DUY NHẤT" (the only counting method, MT2 "ĐẾM LUÔN ĐÚNG BY DEFINITION"). But: the live pivot_definitions table has no owner_gov_code and no approval reference, and the live pivots entered via birth_orphan auto-apply (APR-0093) — so they are governed by law but not bound to an agency owner and not approval-gated in practice.

2. Who owns pivot coverage?

Law: pivot domain → Đ26 primary. Agency: none (agency-orphan). Recommend: GOV-SIV owns pivot coverage/health (it's a verification concern), with GOV-DOT executing pivot declaration/health DOTs. Đ26 is enforced by 8 DOTs (auditor+executor) already.

3. Who can create/change pivots?

Mechanically: DOT only (dot-pivot-declare action ↔ dot-pivot-health monitor). Governance: should be approval_requests type new_dot/schema_add (new pivot row) → Đ32. Today there is no approval gate on new pivots (APPROVAL_PATH_GAP). New rows = INSERT data (Đ26 §0-AU "KHÔNG hardcode. Thêm dòng = INSERT meta_catalog virtual row. KHÔNG sửa code").

4. Approval path for new pivots

Recommended: B-tier dot-pivot-declare raises approval_requests(request_type='new_dot' or 'schema_add', proposed_action_code='create_item'); risk low/medium; on apply, INSERT the pivot_definitions row is_active=false, then a separate activation step. This closes the APPROVAL_PATH_GAP by reusing Đ32 — no new mechanism.

5. How are pivot changes audited?

pivot_definitions has triggers refreshing meta_catalog/pivot_results; Đ26 dual-trigger + 10-min cron. Audit DOT = dot-pivot-health (A-tier). Data changes → registry_changelog. Add to governance_audit_log once an agency owner exists.

6. How are pivot changes rolled back?

Per Đ35 §6.2: backup → patch → dry-run → commit. For a pivot row: is_active=false (soft-disable) + superseded_by, or DELETE the rehearsed row (the prior campaigns proved INSERT-then-ROLLBACK works). Đ30 regression suite protects the rendered surface.

7. How does pivot coverage relate to Registries-Pivot correctness?

Registries-Pivot's entire premise = "every count is pivot-backed or explicitly marked PIVOT_MISSING/CLASSIFICATION_REQUIRED/DATA_MISSING." So pivot coverage IS Registries-Pivot correctness. Missing pivots (PIV-500 grand-total, PIV-301 orphan, PIV-302 phantom, PIV-303 drift, PIV-311 label, PIV-321 pin) are coverage gaps the design proposed; the six backing views were committed read-only in the final ship; the pivot_definitions rows remain DEFERRED (no approval).

8. What issue is raised when PIVOT_MISSING appears?

Today: none — PIVOT_MISSING is not in the enacted law and has no system_issues type. It is a design-package construct. Recommendation (ISSUE_EVENT_GAP, additive): register a system_issues issue_type pivot_missing (issue_class e.g. coverage_fault) + event pivot.coverage_gap in event_type_registry, owned by GOV-SIV, approval-gated to register (Đ45 register-before-emit).

9. Does PIV-500 / orphan / phantom / drift pivot creation require governance approval?

It should. These are new pivot_definitions rows → schema_add/new_dot approval under Đ32. The grand-total PIV-500 must be view-backed SUM over a constant-bucket view (the engine's no-group branch hardcodes count(*) and ignores metric_spec — proven in prior macro work), so PIV-500 depends on a helper view being committed first (RG2). Phantom/drift pivots depend on the phantom definition being enacted (doc 09, LAW_DEFINITION_GAP) → those DEFER until council ratifies.

10. Should pivot coverage repair be a DOT, workflow, manual, or combination?

Combination, all central: scan = A-tier DOT (read-only, auto) detecting PIVOT_MISSING → system_issues; propose = dot-pivot-declare raising an approval_requests; apply = B-tier DOT after Đ32 approval (INSERT pivot row); audit = dot-pivot-health (A-tier). Never a manual hand-INSERT (violates Đ26 1E); never a frontend/Nuxt computation (Đ28).

Central governance path proposed (summary)

Pivot operation	Path
new pivot creation	scan→system_issues(pivot_missing) → dot-pivot-declare→approval_requests(new_dot/schema_add)→Đ32 → B-tier apply INSERT is_active=false → activate
pivot coverage repair	same as above, owner GOV-SIV, exec GOV-DOT
pivot definition retirement	approval_requests(retire) → is_active=false / superseded_by → A-tier verify
pivot result refresh	automatic (trigger + 10-min cron, Đ26) — no approval
count-integrity failure	Đ31 contract → system_issues + event_outbox (auto-detect, no approval to raise)

Verdict

The pivot layer is central by law (Đ26) and reusable, but has two real gaps: (a) no agency owner for the pivot domain (→ GOV-SIV) and (b) no approval gate on new-pivot creation (→ reuse Đ32 new_dot/schema_add). PIVOT_MISSING + phantom/drift pivots additionally depend on new issue/event types and the phantom law clause. Disposition: REUSE the engine; EXTEND with an approval gate + owner; DEFER PIV-302/303 until the phantom definition is enacted.