05 — Aggregate Pivots / PIVOT_MISSING After Graph Commit

Key correction (live evidence wins over the prior doc)

The prior macro recorded that PIV-500/30x/31x "need a pivot-engine extension for view-backed counts." Reading the engine body (pivot_query/pivot_count) live disproves this for the view/table-backed cases: the engine builds SELECT count(*) FROM %I (an identifier) — a view is a valid relation, and a filter_spec already supports =, in, is_null, like, etc. So any single-relation count (table OR view, with a WHERE) is already expressible. The true blockers are now narrowed to:

1. Birth side-effect — inserting a pivot_definitions row fires trg_birth_pivot_definitions → fn_birth_registry_auto (creates a birth_registry row). That is registry-onboarding, beyond this macro's approved parent_code-only mutation scope.
2. Law ratification — orphan / phantom / drift / unmanaged / grand-total are not ratified as RP-grain registry pivots; faking them is forbidden (§11).

Rehearsal proof (BEGIN..ROLLBACK, net-0) — READY pivots

Inserted PIV-311 + PIV-313, ran the engine, observed births, rolled back:

pivot_count(PIV-311) = 219      over information_unit          → node contract: pivot_backed, substrate=information_unit
pivot_count(PIV-313) = 207,940  over system_issues WHERE status='open' → pivot_backed, substrate=system_issues
birth_registry 1,131,998 → 1,132,000 (+2)  — both births landed cleanly (fresh codes, NO composite-defect collision)
ROLLBACK → 0 rows present

Reclassification of every PIVOT_MISSING

pivot	meaning	live value	engine-expressible now?	classification
PIV-311	Information Units total	219	✅ (real table)	READY_TO_ADD (apply-ready bundle; commit owner-gated = adds a registry total + births 1 row)
PIV-313	System Issues (open) total	207,940	✅ (real table + filter)	READY_TO_ADD (apply-ready bundle; commit owner-gated)
PIV-301	orphan total	v_birth_orphan=59	✅ (view)	CANDIDATE_ONLY — needs ratified orphan law-def at RP grain
PIV-302	phantom total	v_birth_phantom=289	✅ (view)	CANDIDATE_ONLY — needs ratified phantom law-def
PIV-303	count-drift total	v_count_drift=3 rows / surplus 21,197	✅ (view)	CANDIDATE_ONLY — drift is a quality flag, not yet a ratified registry object
PIV-312	KG edge total	v_kg_edges_all=2,259	✅ (view)	NEEDS_LAW_DEFINITION — is a graph edge a registry object?
PIV-304	unmanaged / unknown	(undefined)	n/a	NEEDS_LAW_DEFINITION — no definition exists; do NOT fake
PIV-500	grand total (all system objects)	cross-table anchor	❌ (no single relation)	NEEDS_LAW_DEFINITION — needs a ratified anchor set/view (what counts as a system object); then trivially view-backed

Apply-ready bundle (owner-gated — NOT applied this macro)

Two pivots are fully rehearsed and safe to commit when the owner accepts adding them to the registry canon:

INSERT INTO pivot_definitions (code, name, source_object, registry_group, composition_level, species, display_order, filter_spec)
VALUES
 ('PIV-311','Information Units — Total','information_unit','dữ_liệu','atom',NULL,311,'{"filters":[]}'),
 ('PIV-313','System Issues (open) — Total','system_issues','giám_sát','atom',NULL,313,
   '{"filters":[{"field":"status","op":"=","value":"open"}]}');
-- each fires fn_birth_registry_auto (1 birth_registry row per pivot). Rehearse in BEGIN..ROLLBACK first.

Held because: committing crosses into birth row-creation / registry-canon expansion — an owner ratification decision, explicitly outside this macro's scope ("do not drift into birth/governance"). No engine work is required.

Honest stance

PIVOT_MISSING is surfaced, never hidden (count_status=PIVOT_MISSING, unmanaged_count=NULL). Nothing is forced or faked. The remaining items are blocked on ratification, not on engineering.