P3D — Birth System B3-F Onboarding Gate Design

Date: 2026-05-12 Mode: DESIGN ONLY Prerequisite: B3-A COMPLETE

---

1. What B3-F must prevent

Drift scenario	Detection method	Severity
New collection_registry row without coverage_status	coverage_status IS NULL on any registry row that enters managed policy universe	CRITICAL
BIRTH_REQUIRED without species mapping	No species_collection_map row	CRITICAL
BIRTH_REQUIRED without physical table	Table absent from information_schema	CRITICAL
BIRTH_REQUIRED without accepted birth trigger	No trigger with contract/sibling OID	CRITICAL
Birth trigger on birth_registry	birth_registry has contract trigger	CRITICAL
fn_birth_registry_auto_id outside approved scope	Sibling OID on non-approved collection	CRITICAL
Silent UNCLASSIFIED_NEW coverage	New registry row, no policy decision	WARN
Drift between registry ↔ species_map ↔ pg_trigger ↔ birth_registry	Cross-system inconsistency	WARN

---

2. Gate strategy recommendation: C — HYBRID (dry-run → soft → hard)

Option	What	Risk	When
A. PG trigger immediately	Gate fires on collection_registry change	High — untested logic could block legitimate operations	Not now
B. Scheduled health check only	Periodic scan, no enforcement	Low — but reactive, not preventive	Good start
C. Hybrid progressive	B3-F0 dry-run → B3-F1 soft gate → B3-F2 hard gate	Lowest — proves logic before enforcement	RECOMMENDED

Reasoning: Gate logic touches multiple tables (collection_registry, species_collection_map, pg_trigger, birth_registry). Untested gate = risk of blocking legitimate Directus operations. Dry-run proves the logic catches real issues without any enforcement risk.

---

3. Implementation phases

B3-F0: Read-only dry-run (FIRST — this prompt)

Agent scans ALL collection_registry rows, then derives governed/in-scope/birth-required/exempt/deferred subsets from live policy columns. For each relevant subset, checks drift scenarios from §1. Reports what gate WOULD catch. Zero enforcement, zero writes to system tables.

Output: gap report showing exactly which collections would trigger CRITICAL/WARN.

B3-F1: Soft gate (AFTER dry-run reviewed)

PG function + trigger on collection_registry (AFTER INSERT OR UPDATE). On non-compliance: INSERT system_health_checks + system_issues. RAISE WARNING only. Does NOT block INSERT/UPDATE.

B3-F2: Hard gate (AFTER soft gate proven stable — weeks/months)

Same function, but: RAISE EXCEPTION for CRITICAL on governed/locked/law_artifact collections. Blocks non-compliant INSERT/UPDATE. Only activated by explicit GPT/User decision.

Start with B3-F0. B3-F1 and B3-F2 are future steps.

---

4. Gate behavior matrix

Condition	B3-F0 (dry-run)	B3-F1 (soft)	B3-F2 (hard)
Missing coverage_status on governed	REPORT	WARN + issue	BLOCK
BIRTH_REQUIRED without species	REPORT	WARN + issue	BLOCK
BIRTH_REQUIRED without table	REPORT	WARN + issue	BLOCK
BIRTH_REQUIRED without trigger	REPORT	WARN + issue	BLOCK
birth_registry has contract trigger	REPORT	WARN + issue	BLOCK
Sibling OID outside scope	REPORT	WARN + issue	BLOCK
Unclassified new collection	REPORT	WARN + issue	WARN + issue

---

5. Self-expanding principles

□ No hardcoded collection list
□ Accepted functions discovered by proname, not OID integers
□ Approved sibling scope = policy artifact (dot_config or collection_registry metadata), not code
□ Species check via live species_collection_map JOIN
□ Trigger check via live pg_trigger + pg_proc JOIN
□ Counts = computed, not gated by evidence snapshots
□ New collection auto-detected from collection_registry

Approved sibling scope storage: recommend a policy artifact in dot_config, not hardcoded code. It must include both function and collection scope, for example key policy.birth_trigger.accepted_sibling_scope = JSON array of objects like { "function": "fn_birth_registry_auto_id", "collections": ["governance_relations", "law_dot_enforcement", "law_jurisdiction"] }. Gate reads this key. Function-only scope is insufficient because fn_birth_registry_auto_id is accepted only for the approved 3 collections. Any fallback list in B3-F0 is only an evidence snapshot for dry-run comparison, not compliant policy. B3-F1 must not proceed until this policy is materialized in PG or another approved policy store.

---

6. Onboarding flow for new collection

1. Collection created → Directus creates table + collection_registry row
2. Gate detects: coverage_status IS NULL
3. Dry-run/soft-gate issue would be created: BIRTH_ONBOARDING required (B3-F0 only reports; B3-F1 may write issue after separate approval)
4. Human/GPT sets coverage_status + coverage_scope_status
5. IF BIRTH_REQUIRED:
   a. Species decision (existing species or new species birth in entity_species first)
   b. species_collection_map row
   c. Verify physical table
   d. Install birth trigger (trg_birth_<collection> → fn_birth_registry_auto)
   e. Health verification
6. IF EXEMPT: set exemption_reason
7. IF DEFERRED: set review_owner

---

7. Interaction with existing exceptions

Exception	Gate behavior
birth_registry (EXEMPT)	Gate verifies exemption reason present. Does NOT flag as missing trigger.
fn_birth_registry_auto_id (3 scoped)	Gate reads approved sibling list from policy. Does NOT flag these 3 as missing contract trigger.
18 duplicate triggers (B3-A-DUP)	Gate ignores duplicates — checks "at least 1 accepted trigger exists", not "exactly 1".
description_policy unclassified rows	Out of scope — gate checks coverage_status, not description_policy. Count must be re-queried live if reported; prior snapshots varied.

---

8. Rollback

B3-F0 (dry-run): no writes, no rollback needed. B3-F1 (soft gate): DROP TRIGGER + DROP FUNCTION. DELETE system_issues/health_checks created by gate. B3-F2 (hard gate): same as F1 + remove EXCEPTION behavior.

---

B3-F Onboarding Gate Design | 2026-05-12