KB-5901

GPT Directive to Opus — Birth B2 Contract and Coverage Classification

6 min read Revision 1
directiveopusp3dbirth-systemB2contractcoverage-classification2026-05-12

GPT Directive to Opus — P3D Birth B2 Contract + Coverage Classification

Date: 2026-05-12 Issuer: GPT-5.5 Thinking / Incomex Hội đồng AI Receiver: Opus 4.6/4.7 Mode: DESIGN + CLASSIFICATION PROMPT DRAFT ONLY — no execution

0. Verdict

Birth inventory was accepted as PARTIAL. The next task is B2 contract finalization and coverage classification, not implementation.

Open:

P3D_BIRTH_SYSTEM_COMPLETION_B2_CONTRACT_AND_COVERAGE_CLASSIFICATION

1. Required reading

knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-birth-inventory-partial-contract-decisions-2026-05-12.md
knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-completion-readonly-inventory-report.md
knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-birth-inventory-partial-contract-decision-needed-2026-05-12.md
knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-standard-relationship-rules-8-confirmed-2026-05-12.md
knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-completion-architecture-design.md
knowledge/dev/architecture/layer3-information-law.md

Do not search broadly.

2. Mission

Create B2 birth contract design and coverage classification prompt.

Goal:

Every governed collection must have either birth coverage or explicit exemption/defer status.
Every birth row must support the minimum metadata contract or document why not.
Every Entity Living DB relation rule must have a placeholder/hook, using the exact 8 rules from Điều 21.

3. Target outputs

3.1 B2 contract design

Create:

knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b2-contract-design.md

Required sections:

A. Birth engine status — working but incomplete coverage
B. Minimum birth metadata contract
C. Required-at-birth fields and owner policy
D. Required-hook-at-birth fields
E. 8 relationship rules placeholder contract
F. Canonical address policy
G. Birth coverage classification policy
H. Backfill policy for existing objects
I. Implementation boundaries
J. Phase 5C2 impact

3.2 Coverage classification prompt DRAFT

Create:

knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-coverage-classification-readonly-prompt-DRAFT.md

Purpose:

Classify the 137 governed collections without birth trigger into:

BIRTH_REQUIRED
BIRTH_EXEMPT_STRUCTURAL_JUNCTION
BIRTH_EXEMPT_SYSTEM_LOG_OR_AUDIT
BIRTH_EXEMPT_DERIVED_CACHE
BIRTH_DEFERRED_NEEDS_REVIEW

Read-only only.

3.3 B2 report

Create:

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b2-contract-and-classification-report.md

4. B2 design decisions to apply

4.1 Trigger gap policy

Do not blindly add triggers to all 137. Do not ignore them.

Every governed collection must have one of:

birth trigger coverage
explicit exemption
explicit deferred review status

No silent uncovered collection.

4.2 Owner policy

Owner must be part of the birth contract. Current birth_registry lacks birth_owner_ref.

Design owner resolution:

source record owner-like fields
→ source collection owner policy
→ collection_registry owner/governance owner
→ UNKNOWN_OWNER

Do not approve DDL yet. Design only.

4.3 Canonical address policy

Do not require physical canonical_address on every collection.

Use universal birth address:

collection_name + entity_code

Physical canonical_address required only for IU/content-addressable/native-address entities.

4.4 8 relationship rules

Use exact rule names:

IDENTITY
BELONGS_TO
CONTAINS
DEPENDS_ON
USED_BY
TRANSITIVE
PEERS
SIMILAR

Birth role:

IDENTITY = required at birth
BELONGS_TO / CONTAINS = structural hook
DEPENDS_ON / USED_BY = dependency hook
TRANSITIVE = derived later, do not materialize at birth
PEERS = derived by Pivot/facet/classification
SIMILAR = enriched later by vector/Qdrant

Do not invent new relationship categories.

5. Coverage classification prompt requirements

The prompt must be discovery-first and anti-hardcode:

  • no fixed DB credentials;
  • no fixed schema assumption;
  • no hardcoded column names;
  • no hardcoded join paths;
  • no hardcoded counts;
  • use live collection_registry, information_schema, triggers, columns, row counts, FK metadata;
  • if unknown, report UNKNOWN / NEEDS_REVIEW, not guess.

Classification signals may include:

row_count
has_primary_key
is_junction_like
has_foreign_keys
has_status/lifecycle columns
has_user/date columns
has_registry code/name fields
is_log/audit/history-like
is_cache/result-like
is_business/governance/knowledge/entity-like
already has species_map
already has birth rows

Output must include per-collection rationale.

6. Do not do

  • Do not dispatch Agent.
  • Do not write DB.
  • Do not create triggers.
  • Do not add columns.
  • Do not patch functions.
  • Do not patch 5C2.
  • Do not migrate.

7. Expected Opus response

Return only:

  1. B2 contract design path.
  2. Coverage classification prompt DRAFT path.
  3. B2 report path.
  4. Top 8 B2 decisions.
  5. Whether coverage classification prompt is ready for GPT review.
  6. Confirmation: phase5c2_migration_allowed=false and agent_dispatch_allowed=false.

8. Status

birth_b2_contract_design_allowed=true
coverage_classification_prompt_draft_allowed=true
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/directives/gpt-directive-opus-p3d-birth-b2-contract-and-coverage-classification-2026-05-12.md