KB-5C5F

GPT Review — Pack 22 Philosophy Correction: Native Birth Automation

6 min read Revision 1
gpt-reviewpack-22birth-philosophynative-drivenno-hardcodedot-iu-create

GPT Review — Pack 22 Philosophy Correction: Native Birth Automation

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Subject: User correction that Pack 22 is still too tool/manual-centric.

Verdict

User correction is correct. Stop Pack 22 rev1 direction. Revise the design objective.

Pack 22 rev1 frames dot-iu-create as a convenient wrapper, but still leaves the mental model as:

user/agent calls a special birth-aware tool to create IU.

That is not the desired architecture.

The correct architecture is:

any valid entity creation path should be native-born; birth registration, version wiring, health signals, and recovery should be automatic consequences of object creation.

Mothers should not need to know the birth process. The entity should be born and breathe automatically.

Correct philosophy

Main channel

The primary path is not “remember to call a birth tool.”

The primary path should be:

  1. A system/component creates an entity through the normal domain-native creation path.
  2. PG-native triggers/gates enforce required invariants.
  3. Birth registry entry is created automatically.
  4. Version/anchor/metadata wiring is completed automatically where domain rules require it.
  5. The creator only receives success/failure/report.

Auxiliary channel

If an object is discovered already born but missing paperwork:

  1. A scanner/backfill/reconciler detects it.
  2. The system repairs or routes remediation.
  3. A health warning is emitted because main channel failed.
  4. Data remains protected before user-visible failure.

Orphan/ghost channel

Independent detectors must catch:

  • living object without proper registry/paperwork;
  • registry trace for object no longer alive;
  • mismatch between registry and runtime object.

Revised Pack 22 objective

Rename/reframe Pack 22 from:

dot-iu-create wrapper design

To:

IU Native Creation + Auto-Birth Contract Design

Possible path:

knowledge/dev/laws/dieu44-trien-khai/design/22-iu-native-create-auto-birth-contract.md

What dot-iu-create becomes

dot-iu-create may still exist, but only as one adapter/CLI over the native creation contract.

It is not the architecture.

It should be equivalent to calling the native IU creation contract, not a special hand-written ritual.

Required rev2 design sections

§1. Native contract

Define the normal creation contract for information_unit:

  • required business inputs;
  • what the creator supplies;
  • what the system derives;
  • what PG gates enforce;
  • what triggers automatically create.

§2. Automatic responsibilities

System must handle automatically:

  • vocab/default resolution;
  • IU row creation;
  • UV v1 creation;
  • anchor wiring;
  • content hash;
  • birth registry via existing trigger;
  • post-commit verification/report;
  • health signal if birth missing.

§3. PG-first enforcement

State that correctness lives in PG-native gates/triggers/functions, not in agent memory.

Tooling is an adapter, not the source of truth.

§4. Adapter pattern

List possible adapters:

  • CLI dot-iu-create;
  • API endpoint;
  • Directus action;
  • agent tool;
  • batch import.

All adapters must call the same native contract and produce the same invariant results.

§5. Auxiliary engine

Define what happens when an IU exists but birth/version paperwork is missing:

  • do not silently declare success;
  • detect;
  • repair or route to dot-birth-backfill/reconciler;
  • emit warning/health event because main channel missed.

§6. Orphan/ghost detectors

Tie into existing detectors:

  • fn_registry_health() ORPHAN/PHANTOM;
  • birth backfill;
  • orphan/ghost scanners.

Do not redesign them unless evidence shows a specific gap.

§7. Anti-hardcode

No hardcoded vocab, schema count, trigger count, connection, or status semantics.

All dynamic facts must use query-paths and runtime metadata.

§8. Execution split

Before building an adapter, inspect whether a native IU creation function/procedure already exists.

If not, design one PG-native function or transaction contract first, then adapters.

Immediate directive to Opus

Do not proceed with Pack 22 rev1 execution.

Patch Pack 22 to rev2 with the revised philosophy:

  • not “a CLI wrapper creates IU”;
  • instead “IU native creation auto-birth contract”;
  • dot-iu-create is only an adapter over that contract.

Before drafting detailed implementation, Opus should run or request one read-only search/inspection for existing native creation functions/tools for IU, so we do not reinvent an existing mechanism.

Suggested search terms:

  • information_unit create
  • unit_version create
  • fn_iu
  • iu_create
  • dot-iu
  • content_anchor_ref
  • version_anchor_ref
  • fn_iu_birth_gate_layer1
  • fn_iu_birth_gate_layer2

Hard boundaries

  • no runtime mutation;
  • no DOT implementation yet;
  • no Pack 2C dispatch;
  • no raw birth_registry insert;
  • no new birth lifecycle;
  • no hardcoded values;
  • no assuming absence without search/inspection.

Rationale

The system goal is not to make birth paperwork easier for agents to remember. The system goal is to make birth paperwork impossible to forget.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-pack22-philosophy-correction-native-birth-automation-2026-05-05.md