GPT Review — Birth B3-P Policy Storage: Option A Accepted; DDL/Population Prompts Need rev2

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-b3p-policy-storage-and-onboarding-contract.md
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-b3p-policy-storage-ddl-prompt-DRAFT.md
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-b3p-policy-population-prompt-DRAFT.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3p-policy-storage-report.md

Verdict

Option A is accepted directionally: store birth coverage policy as PG-native columns on collection_registry.

However, neither DDL prompt nor population prompt is approved for Agent dispatch yet. Both need rev2 hardening.

Accepted decisions

1. Policy must live in PG, not only KB prose.
2. Option A — columns on collection_registry — is the right default for PG-first/PG-native/PG-driven governance at this scale.
3. B3-P must precede B3-A and B3-F.
4. Two-pass pattern for new PG functions is correct and should become standard:
   • Agent generates compiled function SQL artifact;
   • GPT reviews;
   • User GO;
   • Agent executes reviewed artifact.
5. Governance role → policy mapping is policy, not data inference.
6. Population must not overwrite existing decisions.
7. Population must STOP if new unclassified collections appear.

Why Option A is accepted

Columns on collection_registry are acceptable because collection_registry is already the PG-native collection governance anchor. The onboarding gate and health checks need fast, simple access to policy. A separate table can be considered later if policy history becomes complex, but it is not necessary now.

Accepted policy fields:

coverage_status
coverage_scope_status
coverage_exemption_reason
coverage_review_owner
coverage_decided_at
coverage_decided_by

The names above are design constants, not runtime discovery targets. They are acceptable because this step explicitly creates the policy contract.

Blocking issues in DDL prompt

1. DDL prompt lacks full production-write safety envelope

It needs explicit:

execution log path / fallback
advisory lock exact name
single transaction
compiled SQL preview before DDL
rollback plan
post-rollback verification
KB + VPS log persistence

2. CHECK constraint names and conflict handling are under-specified

The prompt says add CHECK constraints but does not require:

constraint name plan
existing constraint conflict check
validated/not validated decision
exact allowed values check
post-DDL constraint introspection

3. ADD COLUMN compatibility definition is too vague

compatible type must be exact enough:

coverage_status / coverage_scope_status = text-like varchar/text accepted? or exact varchar?
coverage_decided_at = timestamptz exact
coverage_exemption_reason / coverage_review_owner / coverage_decided_by = text/varchar accepted

Define accepted types and BLOCK if incompatible.

4. DDL prompt must remain DDL-only

It already says no data mutation. Keep this strict. Do not backfill policy in DDL prompt.

Blocking issues in population prompt

1. Population prompt hardcodes historical counts in headings

It uses counts like:

29
43
20
11
4
~20
~28
7
3

These may be report evidence, but they must not be operational truth. Replace with:

classification groups derived from approved classification artifact + live recheck

No numeric count should drive execution.

2. approved_governance_role_policy is embedded but not versioned as policy

The governance mapping must be treated as a GPT-approved policy artifact/version, not casual prompt text. Add:

approved_governance_policy_artifact_id
approved_governance_policy_version

3. Population source must be exact and replay-safe

Population should require:

classification artifact path + revision/hash
compiled population map logged before update
per-row old values captured before update
UPDATE ... RETURNING captured rows
rollback exact captured rows, restoring previous values, not blanket NULL

Current rollback resets to NULL, which is only safe if old values were all NULL. But prompt also says don't overwrite existing decisions. To be robust, capture old values anyway.

4. coverage_decided_at and coverage_decided_by policy missing

Population prompt should define how these are set:

coverage_decided_at = transaction timestamp / RUN_STARTED_AT
coverage_decided_by = approved actor string, e.g. GPT_USER_APPROVED_B3P_POPULATION_<date>

But actor string must be locked by GPT/User before dispatch.

5. Direct CMS/Agency heuristics must come from classification artifact

The prompt says CMS/Agency OS buckets. That is acceptable only if extracted from classification report evidence. Agent must not infer CMS/Agency split by name alone during population.

Required next action

Patch B3-P → rev2.

Open:

P3D_BIRTH_B3P_REV2_POLICY_STORAGE_PROMPT_HARDENING

Status

b3p_option_a=ACCEPTED_DIRECTIONALLY
b3p_ddl_prompt=NOT_APPROVED_FOR_DISPATCH
b3p_population_prompt=NOT_APPROVED_FOR_DISPATCH
reason=production_write_hardening_needed_and_population_counts_hardcoded
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
next_action=OPUS_PATCH_B3P_REV2_POLICY_PROMPTS