GPT Review — P3D Pack 1 Phase 3 Investigation BLOCKED + No-Hardcode Directive

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

• knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase3-hash-planner-birth-alignment-investigation-report.md
• Opus verification note after Agent report

Verdict

Agent report is accepted. Phase 3 investigation status BLOCKED is correct.

Do not start TAC→IU migration. Do not seed vocab/species manually yet. Do not patch birth functions yet.

Next work must be a design/governance pack that resolves the blockers using registry-driven, non-hardcoded rules.

Key accepted findings

1. TAC hash and IU hash both use SHA-256 but with different inputs:
   • TAC: sha256(title|body|description|content_profile_or_{})
   • IU: sha256(body) via fn_content_hash
2. law_unit was not a planner bug. The real blocker is missing IU vocab:
   • vocab.unit_kind.design_doc_section exists;
   • vocab.unit_kind.law_unit does not exist;
   • fn_iu_create_plan(p_unit_kind:='law_unit') correctly returns unresolved_vocab.
3. Native IU birth currently enforces Tier-0/core only:
   • no species invariant;
   • no composition role invariant;
   • no parent/child edge invariant;
   • no label/enrichment invariant.
4. species_collection_map is not wired for information_unit / unit_version.
5. entity_labels has 0 IU/UV entries.
6. universal_edges has 0 IU/UV entries.
7. collection_registry for IU/UV is still governance_role=observed, migration_state=pilot, species_code=NULL.
8. TAC tables are outside birth_registry / species_collection_map / collection_registry universe.

Hardcode problem — elevated to blocker

The User is correct: hardcoded counts, table names, species numbers, layer counts, DOT names, and manually enumerated registry facts are recurring risk.

This is now a formal blocker for Phase 4.

Before migration or seeding, all future prompts must distinguish:

Allowed stable identifiers

• Canonical table names being directly modified in a specific DDL pack, e.g. public.information_unit.
• Explicit legal/KB path references.
• Exact function names under review, e.g. fn_iu_create_plan, when investigating that function.

Disallowed hardcoding

• Hardcoded species count, layer count, table count, DOT count.
• Hardcoded lists of section types / publication types copied from memory.
• Hardcoded assumptions such as “33 species”, “6 layers”, “166 collections”, “2199 edges”, “57K entities”, unless explicitly reported as a snapshot and re-verified live before use.
• Seeding exact values without querying the authoritative vocab/registry tables first.
• UI/agent code branching on table names where registry metadata should drive behavior.

Required principle for next phase

Use registry-driven discovery:

• derive section types from tac_section_type_vocab and live TAC data;
• derive publication types from tac_publication_type_vocab and live TAC data;
• derive species/composition decisions from entity_species, species_collection_map, collection_registry, entity_labels, and legal design docs;
• derive layer/composition relationships from registry/edge metadata, not fixed numbers;
• treat all counts as snapshots, not constants;
• create seeds/prompts from queries, not manually typed lists.

Decision

Next phase is not migration and not function patch.

Next phase:

P3D_PACK1_PHASE4_GOVERNED_MIGRATION_READINESS_AND_NO_HARDCODE_CONTRACT

Mode:

DESIGN + READ-ONLY DISCOVERY PROMPT + SEED/PATCH PROMPT DRAFTS ONLY

It must produce one practical pack for Opus 4.6, not many micro-prompts.

Required Phase 4 design decisions

The design must answer:

1. Hash policy:
   • recompute IU hash on migration;
   • preserve TAC source hash in a separate field/table;
   • or store both in a traceability record.
2. Vocab policy:
   • how to seed law_unit and required section/publication types using live vocab discovery, not hardcoded lists.
3. Species/composition policy:
   • whether IU migration requires species/composition wiring before migration;
   • whether information_unit and unit_version should be governed before migration;
   • whether labels/edges are populated at birth, post-birth backfill, or explicitly deferred.
4. Parent-child policy:
   • map TAC parent_id into IU parent_or_container_ref and/or universal_edges without hardcoding hierarchy levels.
5. Governance promotion policy:
   • decide if IU/UV remain observed/pilot or become governed before authoritative TAC migration.
6. No-hardcode migration contract:
   • all future implementation prompts must use discovery queries and registry metadata, with live verification gates.

Status

phase3_investigation=BLOCKED_ACCEPTED
migration_allowed=false
vocab_seed_allowed=false_until_phase4_design_review
birth_patch_allowed=false
next_action=OPUS_CREATE_PHASE4_GOVERNED_MIGRATION_READINESS_AND_NO_HARDCODE_CONTRACT