KB-2CCC

Pre-Birth Admission Control — 00 README First

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

00 — README FIRST

Macro: PRE_BIRTH_ADMISSION_CONTROL_AND_SEQUENTIAL_DOT_WORKFLOW_DECISION Date: 2026-06-03 · Status: PARTIAL · Live mutation: NONE (read-only query_pg)

What this package decides

Whether and how to move the system from "object created → birth trigger/backfill catches it" (after-the-fact) to "birth/admission permit must exist first → insert allowed only with a valid permit → governance handoff follows automatically" (pre-birth admission control). It is not RP cleanup and not backlog cleanup.

The one-paragraph answer

The hooks for pre-birth admission already exist in production (a BEFORE-insert gate on 16 tables, a deferred-finalize constraint-trigger pattern on information_unit, a TTL'd approval-bound permit ledger from Điều 32, and a retire safety-check). But the gate is advisory, so birth-first today is policy, not enforcement. The recommended path is a separate, reversible birth_admission_permit table (Option 2) built from those existing patterns, a composite-unique fix on birth_registry, and a single pilot family (dot_tools) flipped to blocking under owner approval — never a global flip. The governance "second birth" is a decoupled cursor-tail handoff with 0 new tables, gated by OSPA. Nothing was applied; this is design + a rollback-only rehearsal plan.

Read order

doc contents
01 Live verification — birth schema/constraints/triggers, gate bodies, identity per family, governance state. The evidence anchor.
02 Pre-birth permit model — Options 1/2/3, recommendation (Option 2).
03 Sequential DOT workflow — one entrypoint, state machine, idempotency, rollback.
04 BEFORE-guard feasibility — per-family readiness classes, pilot choice.
05 Legacy/backfill boundary — normal vs legacy vs migration vs break-glass; cutoff.
06 Governance second-birth handoff — decoupled cursor-tail, handoff states, OSPA boundary.
07 Intentional misuse & bypass — 20 vectors, blocked/detect/bypassable.
08 Anti-hardcode & self-expanding audit — hardcoded lists, registry-driven replacement, STOP-on-mismatch.
09 Rollout plan — 7 phases, effort/prereq/risk/pass/rollback/approval, ~4–7 weeks.
10 Decision matrix & recommended next macro.
11 Final summary.
12 GPT/MCP-readable checkpoint (in-package copy).

Short external checkpoint: knowledge/dev/reports/architecture/checkpoint-pre-birth-admission-control-2026-06-03.md.

Authority / evidence rules honored

  • Live evidence wins over old reports. Every structural claim in doc 01 is from live query_pg catalog/view reads on prod directus; the SSOT checkpoints were used as the starting state and were confirmed live (BLOCK dims 59/6/16/1).
  • No fake PASS / no self-approval: birth-first is explicitly classified NOT-achieved (gate advisory); superuser bypass is explicitly detect-only, not claimed prevented.
  • Forbidden actions not taken: no RP cleanup, no dot-pivot-update exec/register, no production DOT, no blocking flip, no business-table mutation, no birth_registry constraint change, no fn_birth_gate/fn_birth_registry_auto change, no trigger disable, no gate bypass, no birth_admission_permit created live, no faked OSPA.
Back to Knowledge Hub knowledge/dev/reports/architecture/pre-birth-admission-control-and-sequential-dot-workflow-2026-06-03/00-readme-first.md