KB-21A4

GPT Review — P3D Pack1 Phase5C1 rev1 Candidate Not Approved Transaction Gates

5 min read Revision 1
gpt-reviewp3dpack1phase5c1rev1not-approvedtransactionstop-gates2026-05-11

GPT Review — P3D Pack 1 Phase 5C1 rev1 Candidate Not Approved: Transaction + Stop Gates Needed

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

  • knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-pack1-phase5c1-species-mapping-qt001-backfill-prompt-DRAFT.md revision 3
  • knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase5c1-rev1-dispatch-candidate-patch-report.md
  • knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-p3d-pack1-phase5c1a-probe-pass-lock-species-identity-2026-05-11.md

Verdict

5C1 rev1 candidate is directionally correct but NOT approved for Agent dispatch yet.

The species identity and data values are locked correctly. The prompt has the right safety ideas, but it must become transaction-safe before production write.

What is accepted

  1. Species identity values are correct and GPT-locked.
  2. management_mode='observed' explicit override is required and present.
  3. Collision checks for SPE-IUA and information_unit_atom are required and present.
  4. Mapping dedupe check for information_unit is required and present.
  5. SELECT-before-UPDATE is correct.
  6. Exact-key rollback is correct as a principle.
  7. No TAC migration / no unit_version mapping / no DDL / no function patch is correct.
  8. No numeric gate for 12 target rows is correct; live count must be used.

Blocking issues before dispatch

1. No explicit transaction boundary

The prompt lists INSERT species, INSERT mapping, UPDATE birth_registry, and verifications, but it does not explicitly require one DB transaction or define what happens if Step 2 or Step 3 fails after Step 1 commits.

For production metadata writes, this must be explicit.

Required:

BEGIN;
  all pre-write rechecks that must be transaction-consistent;
  INSERT entity_species;
  INSERT species_collection_map;
  UPDATE captured birth rows;
  verify inserted/mapped/backfilled state;
COMMIT;

If any check fails inside transaction: ROLLBACK, no partial state.

2. Stop-gate semantics are prose, not operational enough

The prompt says ABORT in multiple places, but rev1 should require operational stop behavior:

  • ON_ERROR_STOP=1 for psql or equivalent;
  • no improvisation;
  • no retry with altered SQL;
  • no continuing to later steps after a failed gate;
  • report exact gate name and state.

3. Captured rollback keys must be captured before COMMIT and persisted after COMMIT

Prompt says capture keys and persist KB/VPS, but rev1 should be precise:

  • capture species_id, mapping_id, and birth_id list inside transaction;
  • verify inside transaction;
  • commit;
  • persist final captured keys to KB/VPS report after successful commit;
  • if transaction rolls back, report attempted keys as diagnostic only, not rollback keys.

Do not rely on uncommitted keys as final rollback anchors unless commit succeeds.

4. Pre-write checks should be repeated inside the write transaction

Collision/dedupe checks are currently in GATE-0 read-only pre-state. They must be repeated inside the write transaction immediately before INSERT to avoid stale precheck.

Required repeated checks:

species code collision
species entity code collision
mapping existence for information_unit
backfill target capture count

5. Backfill target capture persistence timing must be clarified

The prompt says write captured_backfill_targets to KB/VPS before mutation. That is good for audit, but if the subsequent transaction rolls back, the artifact must clearly say precommit_target_capture, not committed_backfill_keys.

Final committed report must separately list:

precommit_target_capture
committed_backfill_ids

6. Rollback should require post-rollback verification

Rollback model lists SQL but not verification.

Add required post-rollback checks:

  • inserted mapping id no longer exists;
  • inserted species id no longer exists;
  • captured birth ids restored to prior species/composition values;
  • no unintended rows changed.

7. status = DB default active verification may be too strict if default differs

Probe evidence should be cited if status default is known. If not, rev2 should either:

  • verify default from introspection before expecting active; or
  • mark status check as expected_if_default_active; fail only if probe says default active and actual differs.

Do not hardcode a DB default assumption without linking it to introspection.

Required next action

Patch prompt to rev2 dispatch candidate, not dispatch yet.

Open:

P3D_PACK1_PHASE5C1_REV2_TRANSACTION_SAFE_DISPATCH_CANDIDATE

Status

phase5c1_rev1_candidate=NOT_APPROVED_FOR_DISPATCH
reason=transaction_stop_gate_precision_required
species_identity_locked=true
agent_dispatch_allowed=false
seed_allowed=false
backfill_allowed=false
migration_allowed=false
next_action=OPUS_PATCH_5C1_PROMPT_TO_REV2_TRANSACTION_SAFE_CANDIDATE
Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-p3d-pack1-phase5c1-rev1-candidate-not-approved-transaction-stop-gates-2026-05-11.md