04 — Workstream C: 6 REAL_MISSING Birth Phantoms

Status: BLOCKED_WITH_EXACT_REASON (classified; no lawful retirement mechanism exists)

The 6 stranded birth rows (live)

collection	entity_code	species_code	dot_origin	born_at	cause
collection_registry	COL-171	collection	DIRECTUS	2026-04-19	collection registered+born, then dropped → birth row stranded
collection_registry	COL-172	collection	DIRECTUS	2026-04-19	same
collection_registry	COL-173	collection	DIRECTUS	2026-04-19	same
entity_species	SPE-NRC	species	DOT	2026-04-02	species born, then removed → birth row stranded
entity_species	SPE-NRM	species	DOT	2026-04-02	same
entity_species	SPE-NRR	species	DOT	2026-04-02	same

All 6 are phantom_class=REAL_MISSING: a birth_registry row whose entity row no longer exists.

Evidence gathered (live)

• The 6 codes are referenced nowhere: 0 rows in collection_registry, 0 in entity_species, 0 in species_collection_map. → No FK breakage if retired; no live restore signal.
• They are clustered by origin/date (COL-* = one Directus batch 2026-04-19; SPE-NR* = one DOT batch 2026-04-02), consistent with intentional removal of those entities.

Why no mutation was applied

There is no lawful retirement mechanism for birth rows:

• birth_registry.status is born for all 1,121,521 rows — no retired/superseded value is in use, and there is no CHECK constraint documenting allowed values.
• No retire/supersede function exists (14 *birth* functions; none retires — they are gate, certify, scan, onboarding, auto).
• Directly setting status='retired' (or deleting) would invent a convention/mechanism, which the forbidden list bars: "do not delete birth rows directly unless lawful retirement mechanism exists."

Additionally, retire vs restore is genuinely an owner decision — it requires knowing why COL-171/172/173 and SPE-NRC/NRM/NRR were removed (intentional cleanup vs accidental drop).

Owner decision packet (recommended: RETIRE; NOT applied)

Field	Content
Decision needed	For each of the 6: RETIRE the stale birth row, or RESTORE the entity
Recommendation	RETIRE — no restore signal anywhere; clustered intentional-removal batches
Prerequisite mechanism	Define a governed retirement path first: either (i) a fn_birth_retire(entity_code, collection_name, reason) that stamps a status='retired'/retired_at, or (ii) ratify a status convention + reversible UPDATE. Both are small but are a governance-model decision.
Rollback	If retire = status flip: UPDATE … SET status='born'. If a function: it stamps reversibly.
Effect on guard	birth_phantom_real drops 6 → 0 once the 6 are retired/restored.

Completion: all 6 classified with evidence and exact next action; count not reduced because no

lawful mechanism exists yet → exact blocker recorded (owner decision + retirement-mechanism design).