GPT Review — Birth B3 Design Not Approved: Missing Collection Onboarding Gate

Date: 2026-05-12 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3-trigger-design-and-governance-decisions.md
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3-trigger-implementation-prompt-DRAFT.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3-trigger-design-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-birth-classification-partial-b3-decisions-2026-05-12.md

Verdict

B3 design is directionally useful but NOT approved for Agent dispatch.

The design handles the current uncovered set, but it does not yet solve the user’s core scaling concern:

New collections will appear over time. If the system does not automatically detect and enforce birth coverage for new collections, the design is still hardcode-by-process.

This is unacceptable for a foundational production infrastructure pack.

What is accepted

1. Trigger target = BIRTH_REQUIRED ∩ species-mapped is correct.
2. Do not install triggers on collections without species mapping.
3. coverage_scope_status dimension is correct in principle.
4. unit_version subordinate policy is correct.
5. birth_owner_ref design may remain deferred DDL.
6. PG-first / PG-native / PG-driven remains binding.
7. No external tools in B3.

Blocking issues

1. Missing Collection Onboarding Gate

B3 currently designs trigger installation for the existing classified set, but it does not define how future collections become covered automatically.

Required: add a COLLECTION_ONBOARDING_GATE contract.

For every new or modified collection_registry row, the system must eventually enforce:

coverage_status present
coverage_scope_status present
species mapping if BIRTH_REQUIRED / IN_SCOPE
birth trigger if BIRTH_REQUIRED / IN_SCOPE
exemption reason if EXEMPT
review owner/status if DEFERRED/FUTURE_SCOPE
orphan review if registry row has no physical table

2. Current prompt re-derives classification but does not bind to approved policy

The B3 prompt says it re-derives BIRTH_REQUIRED from live evidence. That is better than a hardcoded list, but it is not enough.

It must also require an approved policy source, e.g. collection_registry metadata or an approved B3 classification artifact. Otherwise the Agent may classify differently on each run.

Required pattern:

Live discovery → compare to approved policy → stop if mismatch → do not improvise.

3. Trigger name and function assumptions need stricter live validation

trg_birth_<collection> and fn_birth_registry_auto may be policy conventions, but the prompt must verify naming/function convention live before applying.

Do not rely on string convention alone.

4. Missing species mapping path

B3 says collections without mapping are skipped, but it does not create a design path to close that gap.

Add:

SPECIES_MAPPING_ONBOARDING_QUEUE

If collection is BIRTH_REQUIRED but lacks species mapping, it must be queued for species mapping decision; not silently skipped.

5. No system_health_checks/system_issues enforcement path

B3 must use PG-native governance artifacts to make missing coverage visible continuously.

Add design for:

system_health_checks rule: birth_coverage_gap_check
system_issues row creation/update for uncovered or noncompliant collections

No execution yet, but design required.

Required next action

Patch B3 → rev2 before any Agent dispatch.

Open:

P3D_BIRTH_B3_REV2_COLLECTION_ONBOARDING_GATE

Status

b3_design_rev1=NOT_APPROVED_FOR_DISPATCH
reason=missing_collection_onboarding_gate_and_future_collection_coverage
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
external_tool_install_allowed=false
next_action=OPUS_PATCH_B3_REV2_COLLECTION_ONBOARDING_GATE