GPT Correction — Existing Birth Pipeline Must Be Reused for IU F6

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Trigger: User objected that existing birth-first and retroactive birth processes already work at scale; F6/file16/file17 over-designed a new path instead of adapting the existing pipeline.

Correction

User is right. Prior GPT/Opus direction around file 16/17 was over-engineered and insufficiently grounded in existing runtime/law/tooling.

The correct first question should have been:

Existing birth pipeline already handles many collections. What is the minimal IU-specific adaptation needed?

Not:

Should we create a new pilot exception governance path?

Evidence found

knowledge/current-state/reports/s145-m2-dot119-birth-triggers-report states:

• DOT-119 dot-birth-trigger-setup exists and is active.
• Usage: dot-birth-trigger-setup --collection=<name> --code-column=<col> [--dry-run].
• It uses shared fn_birth_registry_auto(code_column).
• 133/138 collections were using shared birth triggers.
• Commands were executed through DOT-119, no manual SQL.
• INSERT entity → birth trigger → birth_registry → scanner/ODM.

Therefore, the system already has the general mechanism for data-row birth.

Likely IU-specific gap

IU tables differ from many existing collections because:

• information_unit uses id UUID and canonical_address instead of a conventional code column.
• unit_version is subordinate under information_unit.

Since DOT-119 supports --code-column=<col>, the first hypothesis is:

Use existing DOT-119 on information_unit with --code-column=id or possibly --code-column=canonical_address, after read-only inspection confirms function/tool behavior.

This is a small adaptation/verification problem, not a new birth-law design.

Superseded direction

File 16 rev2 and file 17 rev1 are useful as thinking notes but should be treated as superseded for execution direction until the existing birth pipeline is reconciled.

Do not proceed with file 17 Option B persisted pilot exception as the next step.

Correct next step

Prepare a focused existing-pipeline reconciliation package:

knowledge/dev/laws/dieu44-trien-khai/design/16b-iu0-existing-birth-pipeline-adaptation.md

Purpose: determine how to use the existing DOT-119/fn_birth_registry_auto pipeline for IU rows with minimal adaptation.

Required content:

1. Evidence summary:

   • S145-M2 DOT-119 report;
   • birth-procedures v3.1;
   • law-04-birth-process;
   • Pack 1 IU schema;
   • Pack 2A collection registration;
   • Description Policy ratification.

2. Read-only runtime investigation prompt:

   • inspect /opt/incomex/dot/bin/dot-birth-trigger-setup --help if available;
   • inspect script source enough to confirm --code-column behavior;
   • inspect pg_get_functiondef('fn_birth_registry_auto'::regproc);
   • inspect existing birth trigger definitions for collections using non-code columns such as law_code, measurement_id;
   • inspect birth_registry schema and uniqueness constraints;
   • inspect current triggers on information_unit and unit_version;
   • inspect whether information_unit.id::text or canonical_address is the right birth code;
   • dry-run DOT-119 for information_unit using candidate code columns, no execution.

3. Decision matrix:

   • Option A: DOT-119 with --code-column=id.
   • Option B: DOT-119 with --code-column=canonical_address.
   • Option C: add code column to information_unit only if existing tool cannot use id/canonical_address.
   • Option D: minimal function/tool adaptation only if DOT-119 cannot handle non-text/UUID safely.

4. Recommendation:

   • prefer existing DOT-119 with a valid existing IU column;
   • no new birth exception path unless existing pipeline truly cannot support IU.

5. Scope boundaries:

   • no runtime execution;
   • no new IU rows;
   • no file 17 execution;
   • no Pack 2B until this reconciliation is reviewed.

Key principle

Use existing law/tool/process first. If existing mechanism is missing only a small adapter, adapt the mechanism. Do not invent a parallel governance process.