GPT Review — P3D Pack 1 Phase 5C2 rev2 Candidate Not Approved: Runtime Hardening + Dimensionality Principle

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

• knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-pack1-phase5c2-dieu35-hybrid-pilot-migration-prompt-DRAFT.md rev2
• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase5c2-rev2-complete-schema-concepts-patch-report.md
• User directive on 6+1 species/composition multidimensional matrix

Verdict

5C2 rev2 is much improved but NOT approved for Agent dispatch yet.

The schema concept registry is substantially better and the missing concepts from rev1 have been added. However, before a production migration write, several runtime-hardening issues must be fixed.

In addition, the user’s 6+1 / multidimensional matrix warning has been elevated to a P3D principle and must be referenced in future species/composition work.

New principle recorded

GPT created:

knowledge/dev/laws/dieu44-trien-khai/principles/p3d-multidimensional-species-composition-principle-2026-05-12.md

Key point:

Species + composition must be modeled as multidimensional metadata coordinates, not as a hardcoded tree or CASE ladder. This prevents combinatorial explosion when species and composition layers scale.

What is accepted in rev2

1. Authority value incomex_council is correctly locked.
2. D3a hybrid strategy remains accepted.
3. Expanded concept registry is directionally correct.
4. Birth verification is stronger than rev1.
5. fn_iu_create shape discovery includes rollback residual check.
6. Authority vocab lookup uses resolved config concepts.
7. No TAC writes / no DDL / no function patch remains correct.

Remaining blockers

1. Concepts are declared but resolution algorithm is under-specified

Rev2 lists concepts with “expected” names but does not define candidate lists or deterministic resolution mechanics for each concept.

For dispatch, each concept needs either:

candidate labels list
or exact field locked by prior probe + live verification

and the prompt must state:

0 candidates → FIELD_ABSENT
1 candidate → RESOLVED
>1 candidates → AMBIGUOUS_FIELD

Rev2 states the rule generally, but leaves many concepts as <resolved col> without candidate sources.

2. fn_iu_create result parsing uses abstract key_iu_id / key_uv_id

The prompt says:

new_iu_id := (v_result->>key_iu_id)::uuid;
new_uv_id := (v_result->>key_uv_id)::uuid;

But key_iu_id and key_uv_id are not resolved values. They must come from the shape discovery step and be stored as variables, e.g.:

resolved_fn_result_iu_key
resolved_fn_result_uv_key

If the function returns non-JSONB or nested shape, the prompt must fail before write.

3. fn_iu_create plus identity_profile patch may fail birth-gate timing

The prompt calls fn_iu_create then updates identity_profile.publication_authority_ref afterwards.

But probe said birth gate checks key presence/non-empty. If that gate is active before the post-create patch, fn_iu_create may fail or warn depending on mode.

Rev2 must explicitly preflight this runtime behavior:

• Does fn_iu_create currently require publication_authority_ref at create time?
• Does it warn-only or block?
• Can pilot create proceed then patch identity_profile in the same transaction?

If uncertain, abort and return to GPT. Do not rely on “warning-only” from older probe if current live source has changed.

4. Post-create identity_profile patch may not update birth_registry

If birth_registry row is created before publication_authority_ref patch, species/composition auto-assignment may still be fine due to species_collection_map. But any birth_registry record of identity_profile may not reflect later profile changes if it captures snapshot fields.

Rev2 must verify what birth_registry stores and whether post-create patch affects required birth fields. At minimum, verify birth row species/composition and do not assume authority is represented in birth_registry.

5. tac_lu_owner_ref may be absent or semantically wrong

The prompt uses row.<tac_lu_owner_ref> as owner_lookup_ref, but previous probes showed TAC publication owner is heterogeneous. Logical-unit owner may also be absent/ambiguous.

If owner is required by birth gate, rev2 must define fallback/abort behavior:

if tac_lu_owner_ref unresolved or NULL for any source row → ABORT unless GPT locks fallback

Do not silently use publication owner.

6. Rollback deletes birth_registry rows before target rows without proving trigger behavior

This may be correct, but if target delete triggers also cascade/delete birth rows, exact rollback must be robust.

Rev3 must include rollback rehearsal logic or at least post-rollback verification with exact captured IDs. Since this is prompt-only, add explicit requirement:

rollback procedure must verify zero residual IU/UV/birth rows by captured IDs.
If DELETE order fails, stop and report, do not switch to pattern matching.

7. Multidimensional principle not acknowledged

Rev2 does not mention the user’s scale constraint: 6 composition layers + species/subspecies must be treated as multidimensional metadata coordinates.

Phase 5C2 is allowed to create only atom IU rows, but the prompt must preserve future dimensional metadata and not encode this pilot as global species/composition logic.

Add a short guard:

This migration writes one coordinate: species=information_unit_atom, composition=atom.
It does not implement global 6-layer logic.
All hierarchy metadata is preserved for later edge/bundle/dimensional enrichment.

Required next action

Patch to rev3.

Open:

P3D_PACK1_PHASE5C2_REV3_RUNTIME_HARDENING_AND_DIMENSIONALITY

Status

phase5c2_rev2_candidate=NOT_APPROVED_FOR_DISPATCH
reason=runtime_shape_birth_timing_owner_resolution_dimensionality
publication_authority_ref_value=incomex_council
agent_dispatch_allowed=false
migration_allowed=false
next_action=OPUS_PATCH_5C2_PROMPT_REV3_RUNTIME_HARDENING