GPT Review — Birth B2 Contract OK Directionally; Classification Prompt Needs rev2 + Governance Model

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-b2-contract-design.md
• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-coverage-classification-readonly-prompt-DRAFT.md
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b2-contract-and-classification-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-standard-relationship-rules-8-confirmed-2026-05-12.md

Verdict

B2 contract design is directionally accepted.

Coverage classification prompt DRAFT is not approved for Agent dispatch yet. It still contains residual hardcode/runtime assumptions and the governance model is not sufficiently explicit for scale.

What is accepted

1. Birth contract principle is correct: birth nhẹ nhưng không thiếu.
2. Coverage policy is correct: every governed collection must have trigger, explicit exemption, or explicit deferred review.
3. Universal birth address = (collection_name, entity_code) is correct.
4. Physical canonical_address should not be forced on every collection.
5. 8 relation hooks are correctly confirmed and should use exact names:
   • IDENTITY
   • BELONGS_TO
   • CONTAINS
   • DEPENDS_ON
   • USED_BY
   • TRANSITIVE
   • PEERS
   • SIMILAR
6. Do not blindly create triggers for all 137 uncovered collections.
7. Do not ignore uncovered collections.

Issues to fix

1. Category count/name mismatch

Report says “4 exemption categories” but actual classification includes 5 total statuses:

BIRTH_REQUIRED
BIRTH_EXEMPT_STRUCTURAL_JUNCTION
BIRTH_EXEMPT_SYSTEM_LOG_OR_AUDIT
BIRTH_EXEMPT_DERIVED_CACHE
BIRTH_DEFERRED_NEEDS_REVIEW

Patch wording to “5 coverage statuses” or “1 required + 3 exempt + 1 deferred”.

2. Classification prompt still uses runtime hardcode / brittle shell patterns

Prompt uses:

docker ps ... | grep -i postgres
find / -maxdepth 5 ...

For a read-only prompt this is less dangerous than a write prompt, but it is still too broad/brittle. Replace with discovery rules that prefer known runtime metadata and bounded search:

Use container metadata / compose discovery / env discovery.
If not discoverable, DB_CONNECTION_UNKNOWN.
Do not rely on grep postgres as the only route.
Avoid broad find / unless bounded by discovered project roots; if used, report as fallback with timeout.

3. SQL is marked PATTERN ONLY but still uses collection_registry before table-family resolution

The prompt should add an explicit Phase 0/1 table-family registry and verify collection_registry table exists before using it.

4. Concept resolution is missing for classification prompt

The prompt needs concept resolution for:

collection_key
collection_governance_role
collection_migration_state
trigger_table_name
trigger_name
trigger_event
column_name
column_data_type
column_nullable
fk_source_column
fk_target_table
row_count

Without this, Agent may rely on fixed column names from memory.

5. Decision tree is too naming-pattern-heavy

Naming signals are useful but must not dominate. Classification must use weighted evidence:

schema shape
FK count
PK shape
row count
write path
governance_role
migration_state
species mapping
existing birth rows
naming pattern

Names can be weak signals only.

6. Owner design needs governance model, not only DDL

birth_owner_ref should not be treated merely as “add column later.” Need owner policy registry / resolution chain design:

source record owner field
collection-level owner policy
system/governance owner
UNKNOWN_OWNER with resolution workflow

7. Need governance operating model/tooling section

User explicitly asked how to avoid governance scaling pain. B2 must add a governance model section.

Recommended model:

Metadata catalog + policy-as-code + lineage/dependency graph + PG-first enforcement.

Tool options to evaluate later:

• OpenMetadata / DataHub / Apache Atlas for metadata catalog, glossary, lineage, ownership.
• OpenLineage + Marquez for lineage event standardization if workflows/data pipelines need it.
• OPA/Kyverno-style policy-as-code for infrastructure/policy validation where applicable.
• Bytebase-like operational DB governance for schema/change approval if adopted later.

Do not install tools now. Add an evaluation pack only.

Required next action

Patch B2 → rev2.

Open:

P3D_BIRTH_B2_REV2_GOVERNANCE_OPERATING_MODEL_AND_CLASSIFICATION_PROMPT

Status

b2_contract_design=ACCEPTED_DIRECTIONALLY
coverage_classification_prompt=NOT_APPROVED_FOR_DISPATCH
reason=residual_hardcode_missing_concept_resolution_governance_model_needed
phase5c2_migration_allowed=false
agent_dispatch_allowed=false
next_action=OPUS_PATCH_B2_REV2