KB-BDDE

Pre-Birth Admission Control — 04 BEFORE-Guard Feasibility by Family

8 min read Revision 1
pre-birth-admissionarchitecture2026-06-03

04 — BEFORE-Guard Feasibility by Critical Family

Goal: classify each critical family for "permit required" enforcement. Blocking is proposed for ONE family only; everything else is report-only or blocked-on-prerequisites. Nothing is activated by this macro.

Classes: READY_FOR_STRICT_PRE_BIRTH_GUARD · READY_FOR_REPORT_ONLY_GUARD · NEEDS_IDENTITY_FIX · NEEDS_REGISTRY_ONBOARDING · NEEDS_GOVERNANCE_APPROVAL · NOT_SUITABLE_FOR_PRE_BIRTH.


Readiness table (live-evidence based)

family class has BEFORE gate identity usable pre-insert pilot?
dot_tools READY_FOR_STRICT YES (fn_birth_gate) YES (real code; needs family code-rule) ★ PILOT
collection_registry READY_FOR_STRICT (phase 2b) YES YES (COL-NNN, 99% fmt) no (heavier object)
meta_catalog READY_FOR_STRICT (phase 2b) YES YES (CAT-NNN, 94%) no (gate bootstrap care)
entity_species READY_FOR_REPORT_ONLY → NEEDS_IDENTITY_FIX NO code exists, fmt rule rejects 100% no
pivot_definitions NEEDS_IDENTITY_FIX NO PIV-NNN but collision + no _dot_origin no
pivot_results NOT_SUITABLE_FOR_PRE_BIRTH NO no code at all (derived/cache) no
dot_iu_command_catalog NEEDS_REGISTRY_ONBOARDING + NEEDS_IDENTITY_FIX + NEEDS_GOVERNANCE_APPROVAL NO PK=command_name free-text, triple-absent no
governance tables NEEDS_GOVERNANCE_APPROVAL mixed n/a no (are the substrate)
filesystem DOT lifecycle NOT_SUITABLE_FOR_PRE_BIRTH (DB guard) n/a (no SQL insert) enforce at registrar + reconciler no

Per-family detail

dot_tools — READY_FOR_STRICT (PILOT)

  • Guard condition: for dot_tools, after the 5 shape checks, require a RESERVED permit (='dot_tools', NEW.code); consume it; finalize at commit. Mode → blocking for this family only.
  • Identity resolver: real code (NOT NULL, 0 dups). Caveat: only 163/309 match ^[A-Z]+-[0-9]+$ → pilot must use the dot-registry code convention, validated against the DOT registrar, NOT the hardcoded format rule (see doc 08).
  • Allowed actor/DOT: the DOT registrar (dot-dot-register) / dot-birth-admit. Direct app inserts of dot_tools are rare and governed.
  • Bypass risk: superuser workflow_admin can SET app.bypass_birth_gate / DISABLE TRIGGER — detectable, not preventable (doc 07). Acceptable for pilot with drift monitoring.
  • Rollback: mode→warning, detach gate extension, drop permit table. One-liners; no data migration.
  • Expected breakage: new DOT registration without a permit fails — intended. Backfill of 309 existing rows is grandfathered by cutoff (doc 05). Risk only if registrar isn't wired to issue permits → mitigate by wiring registrar first.
  • Pilot decision: YES. Orphan-clean (0 unborn dot_tools), governed creation path, on-strategy (DOT proliferation control), controlled volume. The 283 phantom are a retire problem (birth-without-object), not an admission blocker for new tools.

collection_registry — READY_FOR_STRICT (phase 2b)

Cleanest identity (166/168). Has both fn_birth_gate and fn_collection_onboarding_soft_gate. Good second family once the pilot proves out, but creating a collection is a heavier, rarer act with more downstream coupling — defer to Phase 5.

meta_catalog — READY_FOR_STRICT (phase 2b, bootstrap care)

Has the gate; 159/169 fmt. Special care: fn_pre_birth_check Check 1 reads meta_catalog to validate the collection — meta_catalog is partly self-referential. A permit-first rule on meta_catalog must not deadlock its own bootstrap. Defer until pilot patterns are proven.

entity_species — READY_FOR_REPORT_ONLY → NEEDS_IDENTITY_FIX

No BEFORE gate today (must install). The ^[A-Z]+-[0-9]+$ rule rejects 100% of entity_species codes (alpha suffixes like SPE-NRC). Strict enforcement is impossible until the format rule is made family-aware (doc 08). Start report-only.

pivot_definitions — NEEDS_IDENTITY_FIX

No BEFORE gate; the collision defect (UNIQUE entity_code alone) actively blocks 5 births (PIV-101/103/104/105/106 owned by pivot_results). Also lacks _dot_origin (Check 2 would fail). Cannot enforce permit-first until: composite-unique fix on birth_registry + add _dot_origin + install gate. This family is exactly why Option 1 (overload birth_registry) is unsafe.

pivot_results — NOT_SUITABLE_FOR_PRE_BIRTH

No code column at all — births are synthetic pivot_results::id. It is a derived/cache table (refreshed by triggers). Pre-birth admission is the wrong tool; treat as a child artifact of pivot_definitions (its identity derives from the definition) or mark BIRTH_EXEMPT_DERIVED_CACHE in collection_registry.coverage_status (the live vocabulary already supports this).

dot_iu_command_catalog — NEEDS_REGISTRY_ONBOARDING + IDENTITY_FIX + GOVERNANCE_APPROVAL

The "smoking gun": 54 rows, 0 in collection_registry / species_collection_map / meta_catalog / triggers / birth. PK = command_name (free text, no code). Cannot have a permit (no stable code, no governance role, no species). Path: owner/taxonomy decides (a) onboard with a real code + species + role, or (b) classify EXEMPT (it is a function-catalog, arguably BIRTH_EXEMPT_SYSTEM_LOG_OR_AUDIT). Until then it is the dominant orphan dimension (54 of 59) and report-only by necessity.

governance tables — NEEDS_GOVERNANCE_APPROVAL

governance_candidate_state, gov_worker_cursor, etc. are the substrate of the handoff itself. Enforcing permit-first on them risks circular dependencies. They are gated by OSPA and handled in doc 06; report-only.

filesystem DOT lifecycle — NOT_SUITABLE_FOR_PRE_BIRTH (in-DB)

A DOT script on /opt/incomex/dot/bin is created by writing a file, not inserting a row — there is no DB BEFORE-INSERT hook to attach. Enforcement belongs at the registrar (dot-dot-register issues the permit + registers the row) and the reconciler (v_dot_fs_reconciliation already flags 16 FILE_NO_REGISTRY). The "permit-first" analog for filesystem DOTs = "registrar issues a permit and registers the row in the same governed action; an unregistered file on disk is a detected violation, not a born object."


Enforcement posture summary

  • Strict (blocking) — exactly 1 family at pilot: dot_tools (after permit table + composite-unique fix + registrar wiring + owner approval).
  • Report-only first: entity_species, governance tables, and the deferred-constraint "permit_missing" finding for all non-pilot gated tables.
  • Blocked on identity/registry/governance prerequisites: pivot_definitions, pivot_results, dot_iu_command_catalog.
  • Out of DB-guard scope: filesystem DOT lifecycle (registrar + reconciler).

No family is switched to blocking by this macro. The deferred-constraint + gate-extension are designed to be installed in report-only mode globally and flipped to blocking per-family only when that family is clean and explicitly approved (open-goal law: no self-approval; fail-closed only where clean).

Back to Knowledge Hub knowledge/dev/reports/architecture/pre-birth-admission-control-and-sequential-dot-workflow-2026-06-03/04-before-guard-feasibility-by-family.md