GPT Review — File 16 F6 Birth Path Design rev1

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/16-iu0-pack2b-f6-birth-path-design.md rev 1

Verdict

Direction partially PASS, but rev2 required before Pack 2B can open.

File 16 correctly identifies the two layers of birth:

1. Domain birth/validation — Pack 1 L1/L2 gates validate IU-specific rules.
2. Governance birth/accounting — QT-002 / birth_registry / species / registry health.

However, the conclusion “defer QT-002 governance birth until governed phase” is too broad and potentially conflicts with the birth-law principle that born entities must be visible/countable unless a formally approved pilot exemption exists.

What is good

• Correctly inventories Pack 1 objects and gates.
• Correctly states Pack 1 L1/L2 are domain-specific validation, not the same as birth_registry governance birth.
• Correctly keeps Pack 2B closed; file 16 is design-only.
• Correctly preserves no vector/outbox/Directus/entity_enrichment.
• Correctly states IU rows are structured_exempt from detailed description.

Main blocker

B1 — “Observed” does not automatically mean governance birth can be skipped

File 16 says IU is observed, therefore QT-002 governance birth can be deferred for Pack 2B pilot. This may be acceptable as a temporary pilot exception, but it must be explicitly framed as an exception with guardrails, not as a general rule.

User has repeatedly emphasized:

• all professional/domain work must follow its governing law;
• birth has law and tooling;
• if not sure, investigate/design before doing;
• “sinh rồi mới khai” exists as a repair path, but should not become the default for new rows.

Therefore Pack 2B cannot simply create real IU rows with no governance birth path unless the exception is clearly scoped and approved.

Required correction

File 16 rev2 must distinguish three cases:

Case A — Transactional test rows only

• Temporary test.% IU/UV rows created inside transaction and rolled back.
• No persistence.
• Pack 1 L1/L2 sufficient.
• No QT-002 required because nothing remains born.

Case B — Pilot persisted IU rows

• Rows remain after commit.
• These are real born entities.
• Need at least one of:
  1. QT-002 governance birth path now; or
  2. explicit pilot exemption: observed + limited namespace + max row count + mandatory later QT-001 backfill + TD + approval.

Case C — Production/governed IU rows

• Must have full governance birth:
  • species decision;
  • species_collection_map;
  • birth_registry integration/backfill;
  • registry health.

Additional issues

B2 — Pack 2B scope currently sounds too broad

File 16 allows CRUD pilot with persisted create/update/delete. If governance birth is deferred, Pack 2B should not be called “minimum production use” or normal CRUD yet. It should be explicitly named either:

• Transactional CRUD smoke only; or
• Persisted pilot with formal birth exception.

B3 — unit_version birth is under-specified

File 16 says no unit_version birth gate needed now. That is plausible for domain validation, but governance semantics still need clarity:

• Is unit_version an entity requiring birth_registry entry?
• Or is it subordinate/version record under IU, exempt from separate governance birth?
• If exempt, this must be explicit under Description/Birth Policy, not assumed.

B4 — Backfill plan must be explicit if QT-002 is deferred

If any persisted IU rows are created before governance birth is wired, file 16 must include:

• max number of rows;
• namespace/scope;
• required cleanup or QT-001 backfill path;
• how to identify all pre-governance rows;
• who approves the exception.

B5 — Need Process Gate alignment with QT-003R/QT-001/QT-002

File 16 references QT-002, but rev2 should explicitly cite canonical birth-procedures.md v3.1 and classify Pack 2B row creation under the right process variant.

Directive to Opus/Ocus

Patch file 16 to rev2. Do not execute.

Required changes:

1. Replace “QT-002 governance birth defer is OK because observed” with a stricter decision matrix:

   • Transactional rolled-back test rows → L1/L2 enough.
   • Persisted pilot rows → require QT-002 now OR explicit pilot exception with backfill obligation.
   • Production/governed rows → QT-002 required.

2. Add a formal Pilot Birth Exception section, if recommending defer:

   • observed only;
   • max row count;
   • allowed namespace, e.g. pilot.% or test.%;
   • no production use;
   • mandatory QT-001 backfill or cleanup before Pack 2C/production;
   • report all persisted rows;
   • User/GPT approval required.

3. Clarify information_unit vs unit_version governance semantics:

   • Does each unit_version need birth_registry?
   • Or is it subordinate to the IU birth?
   • State proposed answer and why.

4. Add Pack 2B scope alternatives:

   • Option A: transactional CRUD smoke only, no persisted rows.
   • Option B: persisted pilot under formal birth exception.
   • Option C: implement QT-002 first, then persisted pilot.

5. Recommend one option.

   • GPT current leaning: Option A first, then decide B/C. This matches “không nhảy quá nhanh” and avoids born-but-unregistered rows.
   • If Opus recommends B, justify with guardrails.

6. Update hard stops:

   • No persisted IU rows unless Option B or C is explicitly approved.
   • No production/minimum use until governance birth/backfill resolved.
   • No Pack 2B execution from file 16 alone.

7. Keep all current no-vector/no-outbox/no-Directus/no-entity_enrichment boundaries.

Current decision

Do not open Pack 2B yet. File 16 rev1 is a useful draft but too permissive around governance birth deferral.

Next step: file 16 rev2 with birth-law compliant option matrix.