Process Candidate Universe — Explainer

Companion content (Topic × Process). Audience: operators & governance. No source IU edited.

What "process coverage" means here

The platform runs 453 distinct entrypoints (373 DB-managed process definitions + 80 host-unmanaged entrypoints). "Process coverage" asks: of everything that runs, how much is recognized as a managed process the Registries-Pivot can list, own, and govern?

Three layers of visibility

1. Official (canon) — a process assigned to the AX-PROCESS axis via axis_assignment. Today this is 0/453 — the AX-PROCESS axis is still a candidate axis awaiting president ratification.
2. Candidate-visible — recognized and listable as a candidate (not yet official). 69 host objects + 19 candidates + 17 clusters sit here. This is what RP shows today.
3. Not-process / OS-level — explicitly excluded: 40 baseline + templates + run-once infra config = noise, shared libs, OS jobs.

The 19 candidates

Built by clustering 143 orphan objects (anti-explosion: 143 → 17 coherent clusters). Of these, 6 are genuinely new managed-process candidates:

• WPC-BACKUP-DR — backup & disaster-recovery routine.
• WPC-PERM-GUARD — permission-guard enforcement.
• WPC-RECONCILE — data reconciliation.
• WPC-HEALTH-MON — health monitoring.
• WPC-CONTENT-PUBLISH — content publishing.
• WPC-APPROVAL-LIFECYCLE — approval lifecycle.

The rest are DOT-implementation clusters, components of existing processes, or not-process.

Verified vs unverified

A candidate is verified only with runtime evidence. Today exactly one is verified: job:cut (8 members, correlated runtime). dot:kg is correlated-dry-run only (no REAL_RUN) — promising but not verified.

Why nothing is official yet

Becoming official requires a human chain: assign axis owner → ratify the axis (canon) → assign process owners → president-gated birth → axis_assignment. Engineering is complete and fail-closed; the gate is governance authority, by design.