KB-3910

T2 RP Systemic Reality Audit — 04 Count Reliability (Systemic)

5 min read Revision 1
terminal2auditcount-reliability2026-06-05

04 — Count Reliability (Systemic)

Score: Count reliability = 70/100. No silently-wrong unlabeled count was found (consistent with T1's parallel count-audit's 76). Divergences are column-labeled. But there are stale-labeled-as-current values, a dual-contract (v1/v2) divergence, partial-shown-as-total triggers, and ledger literals.

Audited counts (live, 2026-06-05, directus)

Count Live value Status Reliability
birth_registry 1,194,873 LIVE OK (grows w/ background)
trigger_guard_alerts 129 LIVE OK
dot_tools 309 LIVE OK
event_type_registry 52 LIVE OK
pivot_definitions 39 LIVE OK
axis_registry 2 (AX-TOPIC, AX-PROCESS, both CANDIDATE) LIVE OK but see "3 synthetic axes"
axis_assignment 25 (all AX-TOPIC) LIVE OK
governance_object_ownership 0 LIVE OK (true zero)
approval_requests 230; PROC-OWN-01..05 all pending LIVE OK
Universal contract nodes 87 (39/22/12/7/7) LIVE OK
proof_matrix_v2 22 PASS + 4 PASS_WITH_EXPECTED_BLOCKER, 0 FAIL LIVE+literal see C2
Trigger universe 525 (DB/dot only) LIVE partial-as-total (C3)
AX-PXT node counts ledger literals (e.g. 408/52/42/8) STATIC C1

Systemic count issues

C1 — AX-PXT counts are static ledger literals; ≥1 stale — DATA_DEBT (P2)

v_process_trigger_actionability_ledger.object_count values are literals, surfaced into the contract with count_status='ledger_backed'. Live proof of staleness: PROC:residual_reconcile shows 8 but live residual hardening (v4) = 2. So a supervisor reading the AX-PXT node sees 8 for a thing that is currently 2. Labeled, but wrong. This is "correct status label on a stale value."

C2 — Proof matrix blocked verdict is a literal — misleading (P1, see H4/doc05)

The 4 PASS_WITH_EXPECTED_BLOCKER rows are partly literal-verdict (the 2 hardcoded-node-array rows can never FAIL). A proof matrix that cannot fail for some rows is a correct-but-misleading "26 PASS / 0 FAIL" headline.

C3 — Trigger universe 525 is partial-shown-as-total — misleading (P2)

525 excludes ~77 host triggers. Any UI tile reading "525 triggers" without a "DB/dot only — host tracked separately" label overstates completeness. The host census exists but is a separate view.

C4 — Dual-contract v1/v2 divergence — stale-shown-as-live (P1)

The same logical question ("does AX-PXT need grouping?") returns different answers depending on which contract you read:

  • v_rp_universal_node_ui_contract (v1): AX-PXT 10 NEEDS_GROUPING, AX-PROCESS 2 substrate_missing (live-confirmed).
  • v_rp_universal_node_ui_contract_v2: AX-PXT 0 NEEDS_GROUPING (grouped). The "closure" (10→0) lives only in v2; v1 is the older, still-live, still-stale contract. If the UI binds to v1 (the un-suffixed name), the supervisor sees the unresolved state. This is a version-sprawl reliability hazard, not a wrong arithmetic — but it means "which view is truth?" is ambiguous.

C5 — "Empty 2→0" is "0 unexplained," not "0 missing" — framing (P3)

AX-PROCESS substrate stays 20/22 available in both v1 and v2. The 2 missing were reclassified as LEAF_EMPTY_BY_DESIGN, not populated. The headline "2→0" means "0 unexplained empties," which is honest in the doc but easy to misread as "0 empties."

C6 — Stale wf_*_digest_v2 tables vs live views — stale-shown-as-live risk (P2)

The digest tables are 06-04 snapshots; the views recompute live. Any consumer (UI tile, report) that reads a digest table instead of the view shows 06-04 data as if current.

C7 — Phantom / test pivots — DATA_DEBT (P2)

PIV-301/302/303/310 referenced-but-absent; MTX-TEST is test data in pivot_definitions. Any code path expecting those phantoms returns empty silently.

What is reliable (credit)

  • No unlabeled silently-wrong count surfaced. Every divergence carries a count_status / governance_status.
  • Core registry counts (births, dot_tools, alerts, ownership=0, votes=0) are LIVE and match across paths.
  • Proof matrix PASS rows (22) are genuinely live-computed via CASE on live grouping/substrate.

Net

Count integrity is good; count currency and singularity are the weak spots: stale ledger literals, a duplicated v1/v2 contract, partial-as-total triggers, and stale digest tables. The fix is mechanical (dedupe to one contract, drive ledger from live counts, label partial scopes) and T1-fixable.

Back to Knowledge Hub knowledge/dev/reports/architecture/parallel-terminal2-rp-systemic-reality-hardcode-autoscale-design-gap-audit-2026-06-05/04-count-reliability-systemic.md