GPT Review — Pack 22 rev2 Native Birth Contract

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/22-dot-iu-create-wrapper-design.md rev2

Verdict

Philosophy PASS. Execution design NOT ready. Rev3 required.

Pack 22 rev2 correctly changes the framing from “CLI wrapper” to “PG-native creation contract.” This matches the User directive: mẹ chỉ sinh, hệ thống tự hoàn thiện giấy tờ.

However, several reliability/scaling issues must be corrected before turning this into execution.

What is now correct

• dot-iu-create is no longer the architecture; it is only an adapter.
• Native contract is PG-first.
• Birth trigger remains the birth mechanism; no raw birth_registry insert.
• Gates/triggers/detectors remain source of enforcement.
• Adapters become thin shells.
• No new birth lifecycle is introduced.

Required rev3 patches

P1 — Separate native contract from adapter contract

Rev2 still starts from a function fn_iu_create(...) with many parameters. This is acceptable as one implementation, but the design should explicitly define the native contract first:

• what minimal business event means “an IU is born”;
• what system derives;
• what invariants must be true after creation;
• what every adapter must call.

Then define fn_iu_create as the current proposed PG implementation.

This avoids treating the function signature itself as the architecture.

P2 — Do not make unit_kind/section_type mandatory ritual

Rev2 still requires caller to supply unit_kind and section_type. This is better than CTE ritual but still not fully “mẹ chỉ sinh.”

Rev3 must support resolution policy:

1. explicit arg if supplied;
2. default profile from dot_config, e.g. iu_create.default_unit_kind, iu_create.default_section_type;
3. derivation from canonical address / caller context if configured;
4. if ambiguous, STOP with available choices.

The core idea: caller should not need to remember vocabulary tokens for normal/default creation.

P3 — Fix transaction/verification semantics

Rev2 says “post-commit verification” but verifies birth inside the function before commit.

Inside fn_iu_create, verification is in-transaction, not post-commit. Deferred L2 constraints fire at transaction commit, which may occur after the function returns if called in a transaction.

Rev3 must specify two verification layers:

• inside function: immediate birth row existence after AFTER INSERT trigger;
• adapter/post-call: after transaction commit, verify IU/UV anchors + birth row.

If using a PG function called by a single SELECT in autocommit, COMMIT happens after function return. A commit-time L2 failure aborts the whole statement, so adapter must handle SQL error.

P4 — Make idempotency race-safe

Current pattern:

PERFORM existing;
IF not found THEN INSERT;

can race under concurrent calls for the same canonical_address.

Rev3 must use one of:

• INSERT ... ON CONFLICT (canonical_address) DO ... where compatible;
• catch unique_violation and return/verify existing;
• advisory lock keyed by canonical_address before create.

Also existing rows must be classified:

• exists_complete;
• exists_missing_birth;
• exists_missing_version;
• exists_anchor_invalid.

No blind already_exists success.

P5 — Verify prerequisites dynamically before create

Rev3 must include preflight checks in design:

• required IU/UV columns exist;
• unique constraint/index for canonical_address exists;
• trg_birth_information_unit exists and enabled;
• fn_birth_registry_auto exists;
• L1/L2 triggers exist/enabled;
• gen_random_uuid() available;
• digest(text,text) or equivalent hash function available;
• collection_registry strategy for information_unit and unit_version matches expected semantics.

Do not assume these forever.

P6 — Hash algorithm should be a policy/helper, not embedded forever

Rev2 says if hash algorithm changes, change one place in function. Better, but still embeds policy in this function.

Rev3 should prefer:

• use existing hash helper if one exists;
• or create/design a separate helper/policy key later, e.g. fn_content_hash(text) or dot_config.content_hash_algorithm.

For v1, digest(..., 'sha256') may be acceptable, but mark as policy dependency and centralization TD.

P7 — Do not run backfill inside create function

Rev2 mostly avoids this, good. Make it explicit:

• fn_iu_create never runs dot-birth-backfill;
• if birth missing, return/warn created_birth_missing and emit health signal;
• remediation is separate auxiliary engine.

This preserves main-channel vs auxiliary-channel observability.

P8 — Health signal must be more than RAISE WARNING eventually

RAISE WARNING is useful but not enough for long-term monitoring.

Rev3 should define v1/v2:

• v1: RAISE WARNING + result status;
• v2 TD: system_health_checks / registry gap event / health table integration.

Do not silently recover without alert.

P9 — Execution split must not say “dry-run creates 1 pilot IU”

Rev2 §7 says:

22-E2 Test: SELECT fn_iu_create(...) dry-run (tạo 1 pilot IU)

This is contradictory. Dry-run must not create rows.

Rev3 execution split should be:

• E0 read-only inspect;
• E1 create function;
• E2 dry-run/plan mode if function supports it, or adapter dry-run only;
• E3 execute one pilot IU;
• E4 verify;
• E5 adapter design/implementation later;
• DOT registration later gate.

P10 — Function should not be named/created before checking existing mechanisms

Rev2 mentions inspection, good. Make it a hard gate:

Before designing exact function signature, perform read-only inspection for existing native IU functions/tools:

• pg_proc for fn_iu%, %information_unit%, %unit_version%;
• DOT scripts for iu_create, information_unit, unit_version;
• API/Directus hooks if known.

If an existing function exists, patch/extend it rather than create fn_iu_create duplicate.

P11 — Permissions/security/RLS need a design note

P2B-P0 found no RLS then, but future environments may add it.

Rev3 must specify:

• function execution role;
• whether SECURITY DEFINER is needed;
• schema qualification for tables/functions;
• search_path safety if SECURITY DEFINER is used;
• no assumption that caller can directly insert IU/UV.

P12 — Adapter must not interpolate SQL strings

Rev2 adapter pseudocode still shows:

psql -c "SELECT fn_iu_create('$addr', '$title', '$body', ...)"

This is unsafe and will fail for arbitrary body text.

Rev3 should state adapters must use safe parameter passing/temp file/JSON payload patterns and never shell-interpolate body into SQL.

Immediate directive to Opus

Patch Pack 22 to rev3.

Do not create execution prompt yet.

Rev3 should be a contract design, not implementation-by-example. It should clearly separate:

1. native IU creation contract;
2. PG implementation candidate;
3. adapter pattern;
4. preflight/read-only inspection gate;
5. later execution gates.

Hard boundaries

• no runtime mutation;
• no DOT implementation;
• no Pack 2C dispatch;
• no raw birth_registry insert;
• no backfill auto-run inside create;
• no hardcoded vocab/connection/schema/counts;
• no SQL interpolation in adapter design.

Short summary

Rev2 has the right hospital philosophy. Rev3 must make the hospital machinery safe under concurrency, schema drift, security changes, and scale.