KB-6CF8

GPT Directive to Opus — Birth B3-P Policy Storage + Onboarding Contract

5 min read Revision 1
directiveopusp3dbirth-systemB3Ppolicy-storageonboardingPG-first2026-05-12

GPT Directive to Opus — P3D Birth B3-P Policy Storage + Onboarding Contract

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

0. Verdict

B3 rev3 direction is accepted, but no prompt is approved for dispatch. Self-expanding infrastructure requires PG-native policy storage first.

Open:

P3D_BIRTH_B3P_POLICY_STORAGE_AND_ONBOARDING_CONTRACT

1. Required reading

knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-birth-b3-rev3-direction-ok-not-approved-policy-storage-first-2026-05-12.md
knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3-trigger-design-and-governance-decisions.md
knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-system-b3-trigger-implementation-prompt-DRAFT.md
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

Do not search broadly.

2. Mission

Create PG-native policy storage design and prompt drafts so birth coverage becomes self-expanding and not report/list-driven.

Do not execute anything.

3. Target outputs

3.1 Policy storage design

Create:

knowledge/dev/laws/dieu44-trien-khai/design/p3d-birth-system-b3p-policy-storage-and-onboarding-contract.md

Required sections:

A. Why policy storage must precede trigger/gate execution
B. PG-native storage options comparison
C. Recommended storage model
D. Policy fields and semantics
E. Governance role → birth coverage policy mapping
F. Policy lifecycle and approval workflow
G. Backfill/populate policy from classification report
H. Onboarding gate dependency on policy storage
I. Periodic health check dependency on policy storage
J. B3 sequence update: B3-P → B3-A → B3-F
K. Anti-hardcode guarantees

3.2 Policy storage DDL prompt DRAFT

Create:

knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-b3p-policy-storage-ddl-prompt-DRAFT.md

DRAFT only. Must be discovery-first and self-contained.

3.3 Policy population prompt DRAFT

Create:

knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-birth-b3p-policy-population-prompt-DRAFT.md

Purpose: populate policy values from GPT-approved classification artifact after policy storage exists.

DRAFT only. No execution.

3.4 B3-P report

Create:

knowledge/dev/laws/dieu44-trien-khai/reports/p3d-birth-system-b3p-policy-storage-report.md

4. Required design decisions

4.1 Policy must live in PG

Policy must not live only in KB report prose.

Recommended options:

Option A: columns on collection_registry
Option B: birth_coverage_policy table
Option C: JSONB policy field in collection_registry/meta_catalog

Evaluate and recommend one.

4.2 Do not over-hardcode governance role values

Live values can be discovered. But role→policy mapping is policy, not mere data.

Design a PG-native mapping artifact, for example:

dot_config keys
universal_rule_registry rules
coverage policy table fields

4.3 Policy fields must support future collection onboarding

Minimum policy concepts:

coverage_status
coverage_scope_status
coverage_exemption_reason
coverage_review_owner
coverage_review_status
coverage_decided_at
coverage_decided_by
coverage_policy_version
coverage_policy_source_ref

4.4 Status values

Use approved values:

coverage_status:
  BIRTH_REQUIRED
  BIRTH_EXEMPT_STRUCTURAL_JUNCTION
  BIRTH_EXEMPT_SYSTEM_LOG_OR_AUDIT
  BIRTH_EXEMPT_DERIVED_CACHE
  BIRTH_DEFERRED_NEEDS_REVIEW

coverage_scope_status:
  IN_SCOPE
  USER_EXCLUDED
  FUTURE_SCOPE
  ORPHAN_REGISTRY
  SYSTEM_MANAGED

If storing values as vocab/dot_config, design vocab keys. Do not seed yet.

4.5 Prompt hardening

All prompt drafts must:

  • be self-contained;
  • use table-family registry;
  • use concept resolution;
  • no hardcoded schema;
  • no hardcoded columns;
  • no CREATE OR REPLACE overwrite;
  • no list-as-truth;
  • exact rollback key capture;
  • advisory lock for any future write;
  • STOP on mismatch.

5. Do not do

  • Do not dispatch Agent.
  • Do not write DB.
  • Do not create columns/tables.
  • Do not populate policy.
  • Do not create triggers.
  • Do not create functions.
  • Do not patch 5C2.
  • Do not migrate.

6. Expected Opus response

Return only:

  1. Policy storage design path.
  2. Policy storage DDL prompt DRAFT path.
  3. Policy population prompt DRAFT path.
  4. B3-P report path.
  5. Recommended storage option and why.
  6. Updated execution sequence.
  7. Confirmation: agent_dispatch_allowed=false, phase5c2_migration_allowed=false.

7. Status

b3p_design_allowed=true
b3p_execution_allowed=false
agent_dispatch_allowed=false
phase5c2_migration_allowed=false
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/directives/gpt-directive-opus-p3d-birth-b3p-policy-storage-onboarding-contract-2026-05-12.md