08 — Anti-Hardcode & Self-Expanding Audit

Goal: find hardcode (and hardcode-disguised-as-policy) in the birth/gate/governance machinery; classify each; decide what may remain as a temporary pilot vs what must become registry-driven before scale. Require STOP on any live-vs-approved mismatch.

Classes: registry-driven · metadata-driven · policy-artifact-driven · hardcoded-acceptable-temporary-pilot · hardcoded-and-unsafe-for-scale.

---

Findings (live-verified)

#	Object	What is hardcoded	Class	Action
H1	fn_pre_birth_check code-format rule ^[A-Z]+-[0-9]+$	one regex for ALL families	unsafe-for-scale	rejects 100% of entity_species (0/42) and 47% of dot_tools (146/309). Replace with per-family code rule from meta_catalog / a dot_config code_format.<collection> policy.
H2	fn_birth_gate 16-table coverage	the set of tables with a BEFORE gate is an install-time hardcoded list	unsafe-for-scale	derive the gated set from collection_registry.coverage_status='BIRTH_REQUIRED' ∩ coverage_scope_status='IN_SCOPE'; reconcile installed triggers vs the registry-derived set.
H3	v_birth_orphan.critical_family flag	which families count as "critical" is baked into the view	unsafe-for-scale	drive from a registry column / dot_config so a new critical family is covered automatically.
H4	fn_iu_gate_open c_never_flip / c_governable arrays	two hardcoded gate-key allowlists	acceptable-temporary-pilot (fail-closed safety allowlist, Điều 32)	acceptable as a safety allowlist; back it with dot_config + review; keep fail-closed default-deny.
H5	fn_birth_registry_auto synthetic-code TG_TABLE_NAME::id	fallback identity scheme	metadata-driven (acceptable)	derives from table+id, not a literal list; fine, but synthetic codes pollute entity_code space (contributed to 283 phantom). Note, don't change.
H6	fn_birth_onboarding_full_scan() vs _hc(cfg jsonb)	no-arg variant may embed defaults; _hc is config-driven	mixed	prefer the _hc(cfg jsonb) config-driven variant; audit the no-arg one for embedded literals.
H7	fn_collection_onboarding_soft_gate sibling policy	reads dot_config['policy.birth_trigger.accepted_sibling_scope'], resolves fns by OID	policy-artifact-driven (good)	exemplar of the right pattern — registry/policy-driven, OID-bound, ambiguity-raises. Use as the template for H1–H3.
H8	fn_iu_birth_gate_layer1 vocab checks	vocab.unit_kind.* etc. read from dot_config	policy-artifact-driven (good)	good pattern; the family-specific required-field set is in code but vocab is in config. Acceptable.
H9	fn_birth_registry_auto default governance_role='excluded'	literal default when collection_registry has no row	hardcoded-acceptable	a safe-default; fine, but means un-registered collections silently become excluded — surface via onboarding gap.
H10	166-table birth-trigger install + 16-table gate install	two separately-maintained literal table lists (drift risk)	unsafe-for-scale	single registry-derived installer; STOP if the two sets disagree with the registry.

---

Known hardcoded critical-family lists (explicit inventory, per macro requirement)

1. fn_birth_gate coverage — 16 tables: agents, checkpoint_instances, checkpoint_sets, checkpoint_types, collection_registry, dot_tools, entity_dependencies, meta_catalog, modules, table_proposals, tasks, taxonomy, trigger_registry, ui_pages, workflow_change_requests, workflow_steps.
2. fn_birth_registry_auto coverage — 166 tables (+3 via _auto_id) — the AFTER-birth install list.
3. v_birth_orphan.critical_family — the safety-net's "critical" predicate (currently surfaces dot_iu_command_catalog, pivot_definitions, …).
4. fn_iu_gate_open allowlists — c_never_flip (2), c_governable (8) gate keys.
5. fn_pre_birth_check — the single code-format regex (a hardcoded rule, the most insidious because it masquerades as policy).

May any remain as pilot-only? Yes: #4 (fail-closed safety allowlist) and the pilot's single-family scope (dot_tools hardcoded as the one enforced family during pilot) are acceptable temporary hardcodes — explicitly logged as pilot scope. Everything in #1/#2/#3/#5 must become registry-driven before enforcement expands past the pilot, or a new family silently escapes the gate (misuse #18).

Registry-driven replacement (proposed, design-only)

• Single source of coverage truth: collection_registry.coverage_status / coverage_scope_status (live vocabulary already includes BIRTH_REQUIRED, BIRTH_DEFERRED_NEEDS_REVIEW, BIRTH_EXEMPT_*, IN_SCOPE, etc.). The set of "gated" tables = BIRTH_REQUIRED ∩ IN_SCOPE; the set of "enforced (blocking)" tables = a subset flagged in dot_config policy.birth_admission.enforced.* with a cutoff.
• Per-family code rule: dot_config code_format.<collection> (regex or named validator); fn_pre_birth_check reads it, defaults to a permissive check (not the rigid PREFIX-NNN) when unset.
• Critical-family predicate: derive from collection_registry / meta_catalog rather than a literal in the view.

STOP-on-mismatch (mandatory gate)

Before any enforcement flip, a guard must compare three sets and STOP (refuse to flip) on disagreement:

installed_birth_gate_tables   (from pg_trigger)
   vs  registry_required_tables (collection_registry BIRTH_REQUIRED ∩ IN_SCOPE)
   vs  approved_enforced_families (dot_config policy.birth_admission.enforced.*)

A new table that is BIRTH_REQUIRED ∩ IN_SCOPE but has no installed gate = a coverage hole → STOP. An enforced family whose gate is missing/disabled = STOP. This converts the silent "hardcoded list missed a family" failure (#18) into a hard stop. It is the self-expanding mechanism: coverage follows the registry, and the guard refuses to run if code and registry have drifted.

Verdict

The machinery is partly registry-driven already (H7/H8 are exemplary), but the enforcement-critical paths (code-format rule, gate coverage, critical-family flag, dual install lists) are hardcoded and unsafe to scale. Pre-birth admission must not be scaled past the dot_tools pilot until H1, H2, H3, H10 are registry-driven and the STOP-on-mismatch guard is in place. The pilot itself may run with a documented single-family hardcode.