GPT Review — Birth B3 rev3 Direction OK; Not Approved: Policy Storage Must Come First

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 rev3
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3-trigger-implementation-prompt-DRAFT.md rev3
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3-onboarding-gate-implementation-prompt-DRAFT.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3-rev3-self-expanding-infra-no-hardcode-patch-report.md

Verdict

B3 rev3 is improved and directionally correct, but still NOT approved for Agent dispatch.

The major hardcode pattern from rev2 — executable PL/pgSQL body inside prompt — has been removed. This is accepted.

However, the system is still not yet an actual self-expanding infrastructure because the policy storage that the gate depends on does not exist yet. Without PG-native policy storage, trigger installation remains a current-set operation and the onboarding gate remains conceptual.

What is accepted

1. B3-A and B3-F are now separated. Correct.
2. B3-A is trigger-only. Correct.
3. B3-F is a separate onboarding gate prompt. Correct.
4. No PL/pgSQL body in prompt. Correct.
5. Gate is described as behavioral contract. Correct direction.
6. Trigger verification by function OID binding. Correct.
7. Exact rollback IDs for issue queue. Correct.
8. DDL conflict handling principle: absent → create, exists same → OK, exists different → conflict. Correct.

Remaining blockers

1. Policy storage is still only a design recommendation

Rev3 recommends new columns on collection_registry:

coverage_status
coverage_scope_status
coverage_exemption_reason
coverage_review_owner
coverage_decided_at
coverage_decided_by

But they do not exist yet. B3-F correctly says it requires policy columns. Therefore B3-F cannot run.

More importantly: until policy storage exists, the system cannot enforce self-expanding coverage. This is still design, not infrastructure.

2. B3-A still relies on KB report as policy source

B3-A uses:

approved_policy_artifact = p3d-birth-coverage-classification-report.md
approved_policy_revision = 1

This is acceptable as evidence for design review, but not sufficient as durable PG-driven governance. The user’s requirement is PG-first / PG-native / PG-driven. Long-term policy must live in PG, not only in KB prose.

3. “Agent derives PL/pgSQL implementation” is risky for B3-F

Removing hardcoded PL/pgSQL from the prompt is correct. But the next implementation prompt cannot simply ask Agent to invent the function from behavior. It must either:

1. compile from a resolved concept map using a constrained template; or
2. first generate a DRAFT compiled SQL artifact for GPT review, then execute only after approval.

No direct Agent-written production function without GPT review.

4. Governance role values from live data are not the same as governed-like policy

Rev3 says governance role values are not hardcoded and will be read from live data. Good for discovery. But deciding which values are “governed-like” is policy, not just data.

Need PG policy mapping:

governance_role -> coverage_scope_default / requires_birth_review / requires_birth_gate

Otherwise Agent may infer policy from observed labels.

5. B3-A and B3-F need a prerequisite sequence

Correct sequence should be:

B3-P: Policy storage design + DDL prompt DRAFT
B3-P2: Policy backfill/populate prompt DRAFT
B3-A: Trigger install for approved BIRTH_REQUIRED + mapped collections
B3-F: Onboarding gate + periodic health check

B3-A may be safe later, but it should not be the first execution if the goal is self-expanding infrastructure.

Decision

Do not dispatch B3-A or B3-F yet.

Open a new sub-step:

P3D_BIRTH_B3P_POLICY_STORAGE_AND_ONBOARDING_CONTRACT

Required next action

Opus must create:

1. PG-native policy storage design.
2. Policy storage DDL prompt DRAFT.
3. Policy backfill/population prompt DRAFT.
4. B3 rev4 sequence update showing B3-P → B3-A → B3-F.

Status

b3_rev3_direction=ACCEPTED
b3a_trigger_prompt=NOT_APPROVED_FOR_DISPATCH
b3f_gate_prompt=NOT_APPROVED_FOR_DISPATCH
reason=policy_storage_not_implemented_and_gate_not_yet_pg_driven
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
next_action=OPUS_CREATE_B3P_POLICY_STORAGE_AND_ONBOARDING_CONTRACT