GPT Review — B3-A2 Blocker Resolution Design — Patched Review — 2026-05-12

Scope reviewed

Reviewed and patched:

• knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3a2-blocker-resolution-design.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3a2-blocker-resolution-design-report.md

Compared against:

• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3a-readiness-rerun-after-b3a1b-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-b3a-readiness-rerun-after-b3a1b-partial-2026-05-12.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3p-policy-storage-ddl-execution-report.md

Verdict

Status: PASS_WITH_GPT_PATCHES_PENDING_OPUS_CONFIRMATION

The Opus design is directionally correct, but GPT patched two governance-critical issues before approval.

Patch 1 — SYSTEM_MANAGED cannot be written into coverage_scope_status

Original design recommended:

coverage_scope_status='SYSTEM_MANAGED'

This conflicts with the live B3-P DDL CHECK constraint. Allowed values are:

IN_SCOPE
USER_EXCLUDED
FUTURE_SCOPE
ORPHAN_REGISTRY

Patched recommendation:

• Use coverage_status='BIRTH_EXEMPT_SYSTEM_LOG_OR_AUDIT'.
• Keep coverage_scope_status within the live allowed set, recommended current value IN_SCOPE unless a separate DDL/design extends the CHECK constraint.
• Put SYSTEM_MANAGED semantics into coverage_exemption_reason, e.g. SYSTEM_MANAGED: self-referential birth system table — recursive trigger risk.
• Do not add a contract birth trigger to birth_registry.

Patch 2 — Variant whitelist is conditional, not naming-based

Original design inferred from _id suffix that fn_birth_registry_auto_id is likely a PK adaptation. GPT patched this to prevent naming-based acceptance.

Patched requirement:

• Before validators accept fn_birth_registry_auto_id as a contract sibling, run a read-only equivalence probe:
  • pg_get_functiondef() for fn_birth_registry_auto and fn_birth_registry_auto_id.
  • Trigger bindings for the 3 variant-only tables.
  • Sample birth rows emitted by those tables, if safe/read-only evidence exists.
  • Confirm the variant differs only in entity-id extraction or other approved compatibility behavior, not in birth semantics.
• Until probe PASS + GPT review, variant status is: accepted-by-design direction, not validator-green.

Accepted design direction after patch

1. birth_registry should be exempted from B3-A trigger install because self-birth recursion risk is real.
2. The 3 variant-bound tables should not be blindly migrated to fn_birth_registry_auto until function source compatibility is understood.
3. The 9 clean trigger candidates can be prepared for B3-A3 only after:
   • birth_registry policy update is executed and verified;
   • variant function equivalence probe is PASS and reviewed;
   • B3-A3 re-verifies live state.
4. Duplicate trigger cleanup and description_policy classification remain separate workstreams.

Patched files / revisions

• B3-A2 design patched through revision 6.
• B3-A2 report patched through revision 3.

Required Opus confirmation

Opus should confirm the GPT patches, especially:

1. Use allowed B3-P policy values; do not write SYSTEM_MANAGED to coverage_scope_status under current DDL.
2. Treat fn_birth_registry_auto_id whitelist as conditional on read-only source/equivalence proof.

Next recommended action

Dispatch Opus or Agent for a B3-A2a read-only variant-function equivalence probe and a B3-A2b birth_registry exemption execution prompt draft. Do not execute policy update or trigger install until GPT reviews the corresponding prompt.

trigger_install_allowed=false
pg_mutation_allowed=false_until_prompt_review
phase5c2_migration_allowed=false
next_recommended_action=OPUS_CONFIRM_PATCHES_THEN_DRAFT_B3A2A_B3A2B