Incomex AI Portal
KB-61E1

GPT Review — Existing Birth Code Column Patterns + Doc Cleanup Directive

8 min read Revision 1
gpt-reviewbirth-pipelinedot-119iu-0doc-cleanupsupersedef6

GPT Review — Existing Birth Code Column Patterns + Doc Cleanup Directive

Date: 2026-05-05 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed:

  • knowledge/dev/laws/dieu44-trien-khai/reports/existing-birth-code-column-patterns-report.md rev 1
  • knowledge/dev/laws/dieu44-trien-khai/design/16b-iu0-existing-birth-pipeline-adaptation.md rev 1
  • User/Opus summary in conversation

Verdict

Agent report PASS. It materially changes the correct IU birth direction.

The report answers the User’s real question: previous birth/backfill processes already solved “no code column” cases. IU should not invent a new process, and file 16/17 are superseded. In addition, file 16b rev1 is also partially superseded because it assumed DOT-119 supports --code-column and preferred canonical_address; runtime evidence shows both assumptions are unsafe.

Key findings from Agent report

  1. Existing system has precedent for no-code entities

    • 5 collections use non-code text columns: table_id, process_code, law_code, measurement_id, pivot_code.
    • 3 collections use fn_birth_registry_auto_id() no-arg variant.

  2. The dominant real pattern is synthetic shell

    • 69,644 / 75,005 birth_registry rows use TABLE::id double-colon synthetic format.
    • 323 rows use TABLE:id single-colon _id variant.
    • 0 rows use bare UUID.
    • 0 rows use path/canonical format.

  3. Current installed fn_birth_registry_auto(text) is v2 and has synthetic fallback

    • It reads to_jsonb(NEW)->>code_column.
    • If that value is NULL/empty, it generates TG_TABLE_NAME || '::' || NEW.id::text.
    • This is how many UUID-PK collections are born without a usable code.

  4. DOT-119 script on disk is stale/dangerous

    • It is v1, has no --code-column CLI, and hardcodes function body without synthetic fallback.
    • Running it could clobber installed v2 fn_birth_registry_auto and remove the fallback used by ~70k rows.
    • Therefore do not run DOT-119 until it is reconciled/fixed.

  5. canonical_address is not the best immediate birth code

    • It is meaningful and human-readable, but it would introduce a new path/canonical entity_code precedent.
    • Existing precedent for UUID-PK/no-code collections is synthetic shell table::uuid.
    • IU should initially follow precedent: information_unit::<uuid> via v2 fallback.

Corrected IU birth direction

Do not use file 17 Option B pilot exception. Do not run DOT-119 as currently installed. Do not prefer canonical_address until governance deliberately approves a new canonical/path entity_code convention.

Correct near-term direction:

  • Reuse current installed fn_birth_registry_auto(text) v2.
  • Create an IU birth trigger in a way that does not reinstall/clobber the function.
  • Trigger can call fn_birth_registry_auto('__force_synthetic__') or another deliberately absent column name, causing v2 fallback to generate information_unit::<uuid>.
  • Alternatively use a proven no-arg _id variant only if its semantics are preferred and compatible, but the dominant current format is double-colon TABLE::id.

This is a small trigger-setup problem, not a new governance process.

Documentation cleanup / supersede requirement

The User is correct: misleading design docs must be explicitly marked to avoid future confusion.

Required doc cleanup:

  1. Patch file 16 rev2 header:

    • Status: SUPERSEDED — do not execute.
    • Reason: existing birth pipeline already supports no-code entities via synthetic fallback; formal pilot exception not needed.
    • Pointer: this GPT review + Agent report.

  2. Patch file 17 rev1 header:

    • Status: SUPERSEDED — do not execute.
    • Reason: Pack 2B pilot exception path replaced by existing birth pipeline adaptation.
    • Pointer: this GPT review + Agent report.

  3. Patch file 16b rev1 to rev2:

    • Status: REVISED AFTER AGENT INVESTIGATION.
    • Remove/strike unsafe assumptions:
      • DOT-119 supports --code-column CLI;
      • canonical_address is preferred immediate code;
      • dry-run DOT-119 is safe/useful.
    • Replace with corrected direction:
      • DOT-119 on disk is stale v1 and must not be run;
      • installed fn_birth_registry_auto v2 synthetic fallback is the path;
      • IU should use synthetic information_unit::<uuid> unless a deliberate governance decision chooses canonical_address.

  4. Create new execution design pack:

    • knowledge/dev/laws/dieu44-trien-khai/design/18-iu0-birth-trigger-existing-pipeline-execution-pack.md

Required contents for file 18

  1. Inputs/evidence:

    • Agent report existing-birth-code-column-patterns-report.md;
    • S145/S160 reports;
    • Pack 1 IU schema;
    • Pack 2A registration;
    • Description Policy ratification.

  2. Scope:

    • install birth trigger for information_unit using current installed v2 function;
    • no function replacement;
    • no DOT-119 execution until script fixed;
    • no IU rows except controlled test if approved;
    • no unit_version birth trigger.

  3. Execution approach options:

    • Option A: direct CREATE TRIGGER trg_birth_information_unit ... EXECUTE FUNCTION fn_birth_registry_auto('__force_synthetic__') or equivalent absent column string, relying on v2 fallback.
    • Option B: use fn_birth_registry_auto_id() only if matching semantics are accepted; note this creates single-colon format unlike dominant v2 fallback.
    • Option C: first repair DOT-119 to match v2, then use tool; likely larger scope and not needed for IU unblock.

  4. Recommended approach:

    • Prefer Option A as minimal, precedent-compatible, no function clobber.
    • However, require exact trigger definition and a read-only/source verification before execution.

  5. Preflight:

    • confirm current fn_birth_registry_auto still contains synthetic fallback;
    • confirm no existing trg_birth_information_unit;
    • confirm information_unit.id exists NOT NULL default UUID;
    • confirm information_unit is in collection_registry and observed;
    • confirm description_policy=structured_exempt;
    • confirm row count 0 or controlled state;
    • confirm birth_registry unique on entity_code.

  6. Test plan:

    • If test row is approved, insert one IU+UV through Pack 1 L1/L2 transaction and verify birth_registry.entity_code = 'information_unit::' || iu.id.
    • If no test row approved, only install trigger and defer row test.
    • Unit_version remains subordinate and no birth trigger.

  7. Rollback:

    • drop trigger only;
    • do not modify function;
    • cleanup any test row and corresponding birth_registry if created, or mark follow-up.

  8. Report path:

    • knowledge/dev/laws/dieu44-trien-khai/reports/iu0-existing-birth-trigger-execution-report.md

  9. Hard stops:

    • if installed function lacks fallback;
    • if DOT-119 is about to be run;
    • if proposed SQL replaces function;
    • if canonical/path entity_code is chosen without explicit approval;
    • if any Pack 2B/vector/outbox/Directus exposure is attempted.

Current decision

Do not execute yet. First, Opus must clean/supersede the misleading docs and draft file 18. After file 18 review, GPT/User can approve a minimal trigger setup execution.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-existing-birth-code-column-patterns-and-doc-cleanup-directive-2026-05-05.md