GPT Review — File 17 Pack 2B Option B Execution Pack rev1

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/17-iu0-pack2b-option-b-persisted-pilot-execution-pack.md rev 1

Verdict

Direction PASS, execution NOT approved. Rev2 required before dispatch.

File 17 correctly implements the chosen Option B direction: persisted pilot under formal birth exception. It keeps the right boundaries: no vector/outbox/Directus exposure/entity_enrichment/governed upgrade/species setup.

However, rev1 is not yet safe enough as an execution pack for persisted IU rows.

What is good

• Uses formal pilot exception from file 16 rev2.
• Limits scope to two pilot IU rows.
• Uses pilot.iu0. namespace.
• Keeps row count under 10.
• Uses Pack 1 L1/L2 domain gate pattern.
• Includes ledger/report/hard stop.
• Does not open production, Pack 2C, vector, or Directus.

Blockers / required fixes

B1 — Missing preflight section

Before any CREATE, execution must verify:

• information_unit row count is 0 or only pilot.iu0.% rows exist;
• unit_version count under pilot namespace;
• collection_registry.description_policy for IU/UV = structured_exempt;
• information_unit and unit_version governance_role = observed;
• required vocab keys still exist;
• Pack 1 L1/L2 triggers exist and are enabled;
• max row limit will not be exceeded;
• no existing duplicate canonical addresses.

B2 — CREATE SQL must use exact RETURNING capture, not placeholders

Rev1 uses <iu1_id>, <uv1_id> placeholders. Execution pack must show exact psql-safe pattern using CTEs or RETURNING variables so Claude Code cannot improvise.

For example, use WITH iu1 AS (... RETURNING id), uv1 AS (... RETURNING id), upd AS (...) SELECT ... or a DO $$ block with variables. The design must be exact enough to execute.

B3 — Content source must be explicit

Rev1 invents two pilot bodies from summaries. This is probably acceptable for a pilot, but it must state whether content is:

• synthetic pilot content; or
• extracted from exact KB documents.

If extracted from KB, cite source paths/sections. If synthetic, mark as pilot_synthetic in identity_profile or content_profile so future agents do not treat it as canonical extracted content.

B4 — UPDATE/new-version phase must be exact and bounded

The new version body is placeholder text: Updated body with more detail.... Rev2 must provide exact body text and exact content_hash method, or defer the update test.

B5 — Cleanup verification query is flawed

Rev1 cleanup verify checks unit_version by subselecting remaining IU rows after deletion:

SELECT count(*) FROM unit_version
WHERE unit_id IN (SELECT id FROM information_unit WHERE canonical_address LIKE 'pilot.iu0.%');

After IU delete, this returns 0 even if orphaned UV rows remain, because the subselect is empty. Must verify using captured pilot IU ids or a pre-cleanup temp/ledger table/list.

B6 — Retain vs cleanup decision must be explicit before execution

Rev1 asks GPT/User to decide retain vs cleanup after report. But the pack itself creates persisted rows under exception. That is okay, but execution prompt must specify whether it should:

• retain rows after report; or
• cleanup at end of run.

GPT current recommendation: retain after this first Pack 2B pilot only if the report ledger is complete and row count is ≤10. This gives actual persisted rows for later read/update checks. But it must be explicitly approved by User/GPT before dispatch.

B7 — Soft-delete/lifecycle test may be unsupported

Rev1 says soft-delete if deleted_at exists. Pack 1 schema listed no deleted_at. Rev2 should either:

• skip soft-delete by default and only inspect schema; or
• use lifecycle_status transition if vocab/constraints allow it.

Do not invent deleted_at behavior.

B8 — Some validation tests are underspecified or risky

• L1 empty title: the title is inside identity_profile, not a physical title column. Test must match actual trigger behavior from Pack 1.
• L2 negative commit test must be inside a transaction and expected to fail/rollback without leaving rows.
• Directus mutation check via directus_activity may be irrelevant because psql is used. It can be dropped or reframed as “no Directus collections exposure”.
• “No vector mutation” should be checked via absence of outbox/vector operations relevant to IU, not TAC columns guessed by agent.

B9 — Report must include formal exception ledger and expiry

Report must explicitly include:

• exception start time;
• all IU/UV ids;
• namespace;
• max-row compliance;
• whether rows retained or cleaned;
• obligation: cleanup or QT-001 backfill before governed/Pack 2C/production.

Directive to Opus/Ocus

Patch file 17 to rev2. Do not dispatch Claude Code yet.

Required changes:

1. Add Phase 0 Preflight with exact SQL for:

   • current IU/UV pilot row count;
   • non-pilot IU row count;
   • governance_role + description_policy for IU/UV;
   • vocab keys;
   • trigger existence/enabled;
   • duplicate canonical addresses;
   • row-limit check.

2. Replace placeholder CREATE/UPDATE SQL with exact executable SQL using RETURNING / CTE / DO block.

3. Mark pilot bodies as either exact KB extracts or synthetic pilot content. If synthetic, record this in JSONB profile.

4. Provide exact new-version update body/hash or defer update test.

5. Fix cleanup verification using captured IDs, not subquery after IU delete.

6. Set recommended dispatch decision:

   • retain rows after report under active exception; or
   • cleanup at end. GPT recommendation for rev2: retain only the 2 IU rows + resulting UV rows, pending User approval, because this is the point of Option B.

7. Remove/adjust unsupported soft-delete and vague Directus/vector checks.

8. Add exact report/ledger fields and exception expiry reminder.

9. Keep hard boundaries:

   • no vector/outbox/Qdrant;
   • no Directus exposure;
   • no entity_enrichment;
   • no governed upgrade;
   • no species/birth_registry setup;
   • no more than 10 IU rows;
   • no production use.

After rev2 upload, GPT/User reviews again before dispatch.