Opus Post-Dry-Run Review — P3D Pack 1 Phase 5 PARTIAL

Date: 2026-05-11 Author: Opus 4.7 For: GPT-5.5 Thinking / Hội đồng AI Run: Phase 5 dry-run rev4

---

1. Verdict: PARTIAL — semantic registry caught real ambiguities, no supplementary agent action needed

The PARTIAL status is CORRECT behavior: 3 AMBIGUOUS_FIELD instances blocked join-dependent queries instead of silently picking the wrong column. In prior versions (without semantic registry), agent would have guessed publication_id and potentially produced wrong membership counts. The registry design proved its value.

Agent compliance: 100%. All 11 goals attempted. 6/6 functions present. Self-audit 11/11 passed. Zero writes. Zero hardcode. Zero fuzzy. All ambiguities reported, not resolved.

---

2. Evidence summary (key findings for GPT/User decisions)

Finding	Value	Source
TAC source rows	86 logical units, 86 versions, 3 publications, 86 members	G1
Nesting depth	Max 2 (3 roots → 38 depth-1 → 45 depth-2)	G3
Address collisions	0	G5
Hash divergence	5/5 confirmed live (TAC composite ≠ IU body-only)	G6
PLAUSIBLE species	8 total: 4 atom + 4 molecule (all observed)	G7
fn_iu_create accepts parent_ref	YES (p_parent_ref uuid)	G8
Birth gate fields all SATISFIED	Layer1 + Layer2 fields present on target	G9
Pilot candidates	3 publications — per-pub metrics BLOCKED by ambiguity	G10

---

3. Three AMBIGUOUS fields to resolve

#	Concept	Table	Matches	Likely resolution	Why split needed
1	publication_link	tac_publication_member	publication_id, logical_unit_id	Split into two concepts: publication_ref (→ publication_id) + logical_unit_ref (→ logical_unit_id)	These are TWO DIFFERENT FKs: one points to publication, one to logical_unit. Same candidate list accidentally captured both.
2	provenance_profile	unit_version	content_profile (jsonb), provenance (text)	Declare content_profile (jsonb) per Phase 4B addendum §7. Register provenance (text) as separate concept provenance_text.	Different types, different purposes.
3	collection_key	collection_registry	name, collection_name	Declare collection_name (confirmed in Phase 4B as the JOIN key used by fn_birth_registry_auto). Register name as collection_display_name.	One is the PG table name (FK-style), one is a display label.

Plus 1 UNREGISTERED field: render_order on tac_publication_member → add to sort_order candidate list or create new concept render_order.

---

4. Nesting decision evidence (for GPT/User)

G3 provides comprehensive structure data. Key observations for the D1/D2/D3 decision:

D1 (preserve) signals:

• Nesting is structural: parents are typed (heading, article, governance_process), children are different types (paragraph, principle, technical_spec)
• fn_iu_create accepts p_parent_ref uuid — planner is parent-aware
• parent_or_container_ref exists on information_unit — schema is ready

D2 (flatten) signals:

• Depth is only 2 (shallow) — could be encoded as sort_order + publication membership
• All 12 current IU rows have NULL parent — IU has never exercised containment
• Simpler species model (all atom, one species)

D3 (hybrid) signals:

• universal_edges with CONTAINS type exists (282 rows system-wide from Phase 4B)
• Could encode nesting as edges instead of FK, preserving atom composition

---

5. Proposed next steps (for GPT/User decision)

Step 1: Resolve ambiguities + re-register

Small prompt update: refine §0.1 registry to split publication_link → 2 concepts, disambiguate provenance_profile → content_profile, disambiguate collection_key → collection_name, add render_order. Then re-run ONLY the blocked goals (G4, G6 provenance, G10, G11).

Step 2: Nesting decision (D1/D2/D3)

GPT/User decides based on G3 evidence + Nuxt rendering needs + editing patterns. This is the ARCHITECTURAL decision that unlocks everything.

Step 3: Species/composition (follows from Step 2)

If D1 → mixed composition → need new species or per-kind species If D2/D3 → uniform atom → can use existing observed/atom species or new

Step 4: Phase 5B executable design

Species_collection_map INSERT + QT-001 backfill + pilot migration design. One coherent pack.

---

6. Summary

Semantic registry worked. AMBIGUOUS caught real problems. Evidence is comprehensive. Three decisions pending: (1) registry disambiguation, (2) nesting strategy, (3) species/composition. These are architectural decisions, not technical gaps.

phase5_dryrun=PARTIAL_ACCEPTED
evidence_complete_except_blocked_goals=true
agent_compliance=FULL
ambiguous_fields_count=3
unregistered_fields_flagged=1
nesting_decision_pending=D1_D2_D3
species_decision_pending=true
next_action=GPT_USER_RESOLVE_AMBIGUITY_THEN_NESTING_THEN_SPECIES