GPT Review — Pack 22 rev3 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 rev3

Verdict

Pack 22 rev3 is directionally strong, but rev4 is required before execution design.

The philosophy is now correct: native PG contract, automatic birth, adapters are thin shells. However, this is a core creation contract and must be hardened against concurrency, schema drift, security changes, and “manual bypass” paths.

What is good

• Native contract separated from adapters.
• fn_iu_create as PG-native implementation candidate.
• Existing mechanism search is a hard gate.
• Race-safety is considered.
• Two-layer verification is recognized.
• SECURITY DEFINER and search_path are recognized.
• Adapter SQL interpolation risk is recognized.
• Dynamic preflight and anti-hardcode principles are present.

Required rev4 patches

P1 — Add native dry-run/plan function; do not duplicate logic in adapters

Rev3 says adapters can have dry-run, but if adapters implement dry-run themselves they may duplicate PG logic.

Rev4 should define a PG-native plan/validate function:

• fn_iu_create_plan(...) RETURNS jsonb
• resolves defaults;
• validates required inputs;
• classifies existing IU;
• reports missing prerequisites;
• returns planned derived facts without inserting rows.

Adapters call fn_iu_create_plan for dry-run and fn_iu_create for execute. This keeps logic native and avoids adapter drift.

P2 — Do not seed hardcoded defaults blindly

Rev3 E3 proposes seeding:

('iu_create.default_unit_kind', 'law_unit'),
('iu_create.default_section_type', 'section')

This is still risky/hardcoded. Earlier runtime used design_doc_section because law_unit may not exist.

Rev4 must change E3:

• inspect available vocab.unit_kind.% and vocab.section_type.%;
• if default config already exists, keep it;
• if absent, do not seed arbitrary values unless execution pack proves chosen values exist and User/GPT approves;
• alternatively require explicit value until default policy is configured.

Default policy is metadata, not embedded assumption.

P3 — Existing classification must verify anchor correctness, not just non-null

fn_iu_classify_existing currently checks anchors non-null only.

Rev4 must classify anchors using exact join:

• version_anchor_ref references a unit_version.id;
• that UV has unit_id = IU.id;
• content_anchor_ref = version_anchor_ref::text;
• first version or expected current version semantics are clear.

Return exists_anchor_invalid if any mismatch.

P4 — UV birth expectation must read metadata, not hardcode subordinate forever

Rev3 I5 assumes UV has no birth row. That is true now but must be metadata-driven.

Rev4 verify invariants should query:

SELECT birth_code_strategy
FROM collection_registry
WHERE collection_name='unit_version';

If strategy is subordinate, expect no birth row. If strategy changes later, verification should adapt or warn that expectation changed.

P5 — Advisory lock key should avoid 32-bit collision risk where possible

hashtext(p_canonical_address) is 32-bit and can collide.

Rev4 should prefer one of:

• pg_advisory_xact_lock(hashtextextended(p_canonical_address, 0)) if available;
• two-key advisory lock using stable namespaced hashes;
• or rely on unique constraint + catch unique_violation, with advisory lock as optimization.

The unique constraint remains the final guard.

P6 — Unique constraint/index must be verified and used as final idempotency authority

Preflight should verify a unique constraint/index exists for information_unit.canonical_address.

Creation should either:

• use INSERT ... ON CONFLICT (canonical_address) if compatible; or
• catch unique_violation and classify existing row.

Do not rely only on advisory lock.

P7 — Security definer must be stricter

Rev3 uses:

SECURITY DEFINER SET search_path = public

For security-definer functions, rev4 should specify:

• schema-qualify all tables/functions where practical (public.information_unit, etc.);
• use safe search_path, e.g. SET search_path = pg_catalog, public or explicitly explain PostgreSQL pg_catalog behavior;
• function owner must be controlled;
• revoke PUBLIC execute by default;
• grant execute only to intended roles.

P8 — Preflight should validate required input values, not only runtime objects

Rev4 should explicitly check:

• canonical_address non-empty;
• title non-empty;
• body non-null, optionally non-empty depending policy;
• actor non-empty;
• parent_ref exists if supplied, or state whether it is free reference;
• publication_type valid if supplied.

L1 gate may validate vocab, but native function should fail fast with clear messages for basic input.

P9 — Avoid SET CONSTRAINTS ALL DEFERRED if narrower targeting is possible

SET CONSTRAINTS ALL DEFERRED may affect unrelated constraints inside caller transaction.

Rev4 should inspect exact deferrable constraints/triggers needed and prefer a narrower statement if possible. If PostgreSQL limitation makes this impractical, document why ALL is acceptable and require adapter to call in a fresh transaction.

P10 — Direct INSERT bypass must be acknowledged as existing but non-canonical

The user’s philosophy says any valid creation path should auto-complete birth/paperwork. But if someone raw-inserts information_unit, it may bypass the new function and still rely on triggers only.

Rev4 should define:

• canonical native creation path = fn_iu_create / adapters;
• raw direct INSERT is non-canonical and should be restricted by permissions or monitored;
• auxiliary/orphan detectors handle bypass cases;
• future hardening: revoke direct INSERT from app/agent roles and require EXECUTE on function.

P11 — Health signal path must be designed as TD with legal owner

Rev3 says health signal TD. Rev4 should assign owner:

• Đ43/system health for system_health_checks / registry health event;
• Đ4/Birth law for birth semantics;
• not hidden inside Pack 22 execution.

P12 — Execution split should separate function creation from pilot row execution

Current E1/E2/E3/E4 may still be too compressed.

Rev4 should propose gates:

• 22-P0 read-only inspect existing mechanisms and schema;
• 22-P1 create helper/function only, no IU rows;
• 22-P2 dry-run/plan tests only;
• 22-P3 execute one pilot IU;
• 22-P4 adapter CLI only after PG function passes;
• 22-P5 optional DOT registration.

No phase should combine function DDL + pilot DML without an approval gate.

Immediate directive to Opus

Patch Pack 22 to rev4 with P1–P12. Do not create execution prompt yet.

After rev4, return for GPT/User review.

Hard boundaries

• no runtime mutation yet;
• no DOT implementation yet;
• no Pack 2C dispatch;
• no raw birth_registry insert;
• no adapter logic duplicating native PG logic;
• no hardcoded defaults;
• no unsafe SQL interpolation.

Summary

Rev3 has the right hospital model. Rev4 must make the hospital machinery robust: dry-run native, default policy metadata-driven, idempotency race-safe, security-definer safe, bypass monitored, and execution gated.