P3D — Birth System B3 Design rev3 — Self-Expanding Infra

Date: 2026-05-12 Rev: 3 (policy storage, separated B3-A/B3-F, health check, no PL/pgSQL in prompt) Mode: DESIGN ONLY

---

1. B3 structure (SEPARATED)

Sub-task	Prompt	Risk	Content
B3-A	Trigger install prompt	Medium — DDL only	Install birth triggers for approved ∩ species-mapped
B3-F	Onboarding gate prompt (SEPARATE)	Higher — new function + trigger + policy read	Self-expanding infrastructure
B3-B–E	Design only	None	Governance decisions (no prompt)

B3-A and B3-F are NEVER merged into 1 execution prompt.

---

2. PG-native coverage policy storage

Design decision: columns on collection_registry

Option	Pros	Cons	Recommendation
Columns on collection_registry	Simple, JOIN-friendly, existing table	ALTER TABLE needed	RECOMMENDED
JSONB column	Flexible	Harder to query/index	Fallback
Separate table	Normalized	Extra JOIN, more DDL	Over-engineering

Recommended new columns on collection_registry:

coverage_status          — BIRTH_REQUIRED | BIRTH_EXEMPT_JUNCTION | BIRTH_EXEMPT_LOG | BIRTH_EXEMPT_CACHE | BIRTH_DEFERRED
coverage_scope_status    — IN_SCOPE | USER_EXCLUDED | FUTURE_SCOPE | ORPHAN_REGISTRY | SYSTEM_MANAGED
coverage_exemption_reason — text (NULL if not exempt)
coverage_review_owner    — text (NULL if not deferred)
coverage_decided_at      — timestamptz
coverage_decided_by      — text (actor)

This is design. DDL NOT in B3-A. DDL = separate step after GPT approves.

Gate function reads these columns. If columns don't exist yet → gate reports POLICY_STORAGE_NOT_READY, does not crash.

---

3. Onboarding gate behavioral contract (NO PL/pgSQL in design)

What the gate DOES (behavioral contract)

WHEN: new row inserted into collection_registry, OR governance_role updated
IF: governance_role suggests coverage needed (governed/locked/law_artifact/observed)
THEN check 5 conditions:
  1. Physical table exists in schema
  2. coverage_status is non-NULL (policy decided)
  3. IF coverage_status = BIRTH_REQUIRED: species mapping exists
  4. IF coverage_status = BIRTH_REQUIRED: birth INSERT trigger exists with correct function binding
  5. IF coverage_status = EXEMPT: exemption_reason is non-NULL

FOR each failed condition:
  Create system_health_checks row (type=BIRTH_COVERAGE_GAP)
  Create system_issues row (category=BIRTH_ONBOARDING) if no open issue exists

Stage 1+2 = audit + issue. No blocking. No RAISE EXCEPTION.

What the gate does NOT contain in prompt

NO literal column names
NO PL/pgSQL function body
NO NEW.field_name references
Agent derives implementation from live schema after concept resolution

---

4. Periodic health check (complement to row trigger)

Row trigger catches new/changed rows. But misses: pre-existing gaps, disabled triggers, tables created after registry, policy changes outside trigger path.

Design: birth_coverage_gap_check

Behavioral contract:
  Scan ALL governed collections in collection_registry
  For each: check same 5 conditions as gate
  Report: total gaps, new gaps since last check, resolved gaps
  Output: system_health_checks rows + system_issues for new gaps

Execution: Agent-driven or scheduled (cron/pg_cron)
Frequency: daily or on-demand

This is the "sweep" that catches everything the row trigger misses.

---

5. B3-A trigger install design (updated)

Policy matching (3-set + approved artifact)

Required inputs:
  approved_policy_artifact = classification report path + revision
  approved_policy_hash = report revision number or content hash

At runtime:
  load approved_target_set from KB report (BIRTH_REQUIRED list)
  derive live_birth_required_set from governance_role + schema shape
  derive live_species_mapped_set from species_collection_map

  trigger_target_set = approved_target_set ∩ live_birth_required_set ∩ live_species_mapped_set
  species_queue_set = live_birth_required_set − live_species_mapped_set

  IF approved_target_set ⊕ live_birth_required_set is non-empty:
    STOP → POLICY_MISMATCH → report diff → return to GPT

DDL conflict handling

For each trigger to create:
  IF trigger absent on table → CREATE TRIGGER
  IF trigger exists AND function binding = fn_birth_registry_auto → ALREADY_EXISTS_OK
  IF trigger exists AND function binding ≠ fn_birth_registry_auto → BLOCKED_EXISTING_CONFLICT

No CREATE OR REPLACE. Verify by function OID binding, not trigger name alone.

Trigger verification

After creation, verify each trigger:
  table = correct
  event = INSERT
  timing = AFTER
  function = fn_birth_registry_auto (by proname/oid, not trigger name pattern)

Species queue exact IDs

Species mapping queue entries (system_issues):
  INSERT ... RETURNING <system_issue_pk>
  Capture all returned IDs
  Rollback deletes by captured IDs, not by category/timestamp

Rollback

All rollback uses exact captured artifact:
  trigger names from installed_list
  system_issues IDs from species_queue_captured_ids
No deletion by timestamp, category, or pattern

---

6. B3-B through B3-E (unchanged from rev2)

coverage_scope_status, ORPHAN_REGISTRY_REVIEW, HOOK_TABLE_POLICY, birth_owner_ref — design only.

---

7. Anti-hardcode enforcement for ALL B3 prompts

□ NO PL/pgSQL function body in prompt (behavioral contract only)
□ NO literal column names in executable context
□ ALL columns from concept resolution
□ ALL table names from table-family registry + existence check
□ DDL conflict check before CREATE
□ Rollback by exact captured IDs
□ Policy source = KB artifact with revision/hash
□ STOP on live-vs-approved mismatch
□ Trigger verified by function binding, not name pattern
□ Agent compiles all implementation from live schema

---

B3 Design rev3 | Self-Expanding Infra | No Hardcode | 2026-05-12