04 — PIV-304 Unmanaged & PIV-500 Grand Total (Workstream C)

Goal: prevent fake grand totals. Neither is left vague; neither is faked. Both are surfaced in v_rp_aggregate_candidate_register with an explicit law blocker.

PIV-500 — Grand total of all system objects

Status: NOT_A_PIVOT_BUT_EQUATION_VIEW (DEFER as a single number).

A grand total is not a single-relation count, so it cannot be a normal pivot. It is the closure of an accounting equation:

total_system_objects = counted_in_registries_pivot
                     + orphan      (unborn / missing-birth)
                     + phantom     (registered-but-absent / stranded)
                     + unmanaged   (no registry / unknown)

What each term would include (proposed, for ratification)

term	included objects	live anchor today
counted	pivot-backed leaf counts over the leaf set (composition_level≠'meta', not a _total/rollup)	FINAL, live
orphan	birth-grain unborn	v_birth_orphan = 59 (CANDIDATE)
phantom	registered-but-absent	v_birth_phantom = 289 (CANDIDATE)
unmanaged	no governance owner / no birth / not registry-managed / file-only	undefined (PIV-304)
excluded by default	system_issues, IU, KG edges — these are content/operational objects, already their own pivots (PIV-313/311/312); folding them into a single "system objects" total would double-count and conflate object classes	—

Why it is blocked

• No ratified anchor set: "what counts as one system object" is not defined (a DB row? a registry entry? a birth? a file?). Different anchors give wildly different totals.
• unmanaged (PIV-304) is undefined ⇒ the equation has a free variable ⇒ closure is UNVERIFIABLE.
• Once an anchor set is ratified, PIV-500 becomes a trivial equation view (not a pivot): a view summing the ratified terms. We do not publish a number now.

Decision

Surface count_integrity_status = unverifiable_at_grand_total (already live in v_count_integrity), keep PIV-500 as EQUATION_VIEW in the register with live_count = NULL. Do not fake a grand total.

PIV-304 — Unmanaged / unknown

Status: NEEDS_LAW_DEFINITION (DEFER).

There is no ratified definition. Candidate definitions, none yet chosen by the owner:

1. No governance owner — object with no ownership record in the governance layer.
2. No birth — exists in a table but fn_birth_registry_auto never created a birth_registry row (note: birth is currently near-universal via AFTER triggers, so this set may be ~empty).
3. Not registry-managed — exists but its collection is not in collection_registry as a managed/governed collection.
4. File-only — a filesystem artifact (/opt/incomex/dot/bin) with no dot_tools/registry row (16 such files found in prior FS-reconciliation macro).

Each definition yields a different population and must not be silently chosen. The honest surface today is unmanaged_count = NULL (already in the node contract) + register row NEEDS_LAW_DEFINITION.

Law-definition draft (for owner ratification)

Unmanaged object = a discoverable artifact (DB row in a non-registry collection OR a filesystem dot-artifact) that has neither a birth_registry row nor a governed collection_registry/dot_tools entry. Counted by a future view v_unmanaged_objects once the discovery surface (DB + FS) is agreed. Until ratified: NULL, never 0.

Completion

PIV-500 and PIV-304 are no longer vague: PIV-500 = equation-view/deferred, PIV-304 = law-draft/deferred. Exact blockers documented; nothing faked.