02 — Global Blockers vs RP-Specific Risk

RP cleanup = update composition_level on PIV-001/016/021 (the 3 born rows the live view flags mismatch). matrix_spec excluded; naming/registry_group are council-gated.

Per-dimension classification

A. orphan_critical = 59

A1 — 54 dot_iu_command_catalog: not RP (different collection, never read by a pivot update). Keep in global guard. Dependency: owner taxonomy + dot-dot-register creds. Verdict: NON-RP blocker. A2 — 5 pivot_definitions (PIV-101..106): RP-family but NOT cleanup targets (different rows, unborn by entity_code collision; updating the 3 targets does not depend on them). Out-of-cleanup-scope, flagged; birthing them is a separate one-way-door step. Keep in global guard. Verdict: RP-family, not a cleanup-target blocker.

B. phantom_real = 6 (COL-171/172/173, SPE-NRC/NRM/NRR)

collection_registry / entity_species codes, not pivots. Keep guard. NON-RP blocker.

C. fs_no_registry = 16

14 NON-RP ops scripts (apr-types, context-pack, dieu43-fs, hc-executor, ops-silent-fail, search-canary); 1 peripheral RP-family dot-cron-matrix-setup (not needed for the 3 fixes); 1 RP-cleanup-relevant dot-pivot-update. 15 of 16 NON-RP.

D. dot_pivot_update_not_governed = 1

Directly the tool gate. THE single genuine RP-cleanup blocker.

Net distinction (no guard weakened, no count gamed)

Global guard correctly BLOCKs all 4 dims — keep as-is. RP-specific risk collapses to ONE item: register/birth dot-pivot-update. This distinction is analytical (documented here only); it is NOT implemented by removing anything from the global guard or adding any accepted exception.