Incomex AI Portal
KB-2FFE

Opus Review — P3D Pack 1 Phase 5C2A Probe PASS — Authority Decision Needed

6 min read Revision 1
p3dpack1phase5c2areviewprobe-passauthority-decision

Opus Review — P3D Pack 1 Phase 5C2A Probe PASS

Date: 2026-05-12 Reviewer: Opus (Claude) Reviewed: Agent probe report + Agent terminal output Report: knowledge/dev/laws/dieu44-trien-khai/reports/p3d-pack1-phase5c2a-publication-authority-ref-probe-report.md Probe prompt: knowledge/dev/laws/dieu44-trien-khai/prompts/p3d-pack1-phase5c2a-readonly-publication-authority-ref-probe-prompt.md rev2

1. Agent compliance verification

Requirement Status
12/12 output fields returned PASS
Report uploaded to KB (7 sections A–G) PASS
0 mutation (no INSERT/UPDATE/DELETE/DDL) PASS
4-phase execution (introspect → resolve → query → function analysis) PASS
All authority-like columns labelled candidate_not_approved PASS
Agent did NOT decide authority value PASS
No nested/secondary Agent dispatch PASS
FIELD_ABSENT → UNKNOWN (not guessed) PASS
Function analysis bounded (boolean flags only) PASS

Verdict: Agent PASS. No supplementary work needed.

2. Evidence summary (what probe discovered)

2.1 Vocab layer — EMPTY

dot_config has 0 rows matching vocab.publication_authority.*. Only vocab.publication_type.law and vocab.publication_type.design_doc exist. The system has never defined publication authority as a governed vocabulary.

2.2 TAC publication layer — 3 candidates, all weak

Column Data quality Values
owner Populated but heterogeneous S178-FIX23, incomex_council, INCOMEX
approved_by NULL across all 3 rows —
council_score NULL across all 3 rows —

owner is the only non-null authority-like column, but its values are inconsistent: one is a sprint operator tag, one a governance body name, one an org name. Not vocab-bound.

All 3 publications have lifecycle_status = proposed — none formally enacted.

2.3 IU layer — key absent

0/12 existing information_unit rows have publication_authority_ref in identity_profile. Current keys: title, owner_lookup_ref, primary_section_type_ref only.

2.4 Birth gate — checks key, does NOT validate value

fn_iu_birth_gate_layer1 reads identity_profile->>'publication_authority_ref'. If NULL/empty → RAISE WARNING (pilot mode). Does NOT validate against dot_config vocab. In contrast, publication_type_ref IS vocab-validated. This asymmetry is a design gap.

2.5 fn_iu_create — does NOT handle this key

fn_iu_create builds identity_profile from p_title, p_owner_ref, p_section_type, and conditionally p_publication_type. No publication_authority parameter exists. No insertion of publication_authority_ref key. Pilot migration must supply this value through a different write path (direct identity_profile JSON construction or UPDATE after create).

3. Opus assessment

The probe reveals a structural gap: birth gate expects a key that nothing in the system produces. This gap has been latent since birth gate was written — now exposed by the pilot migration requirement.

For 5C2 to proceed, GPT/User must decide:

  1. What value goes into publication_authority_ref?
  2. Whether to seed vocab for it (like publication_type has vocab)?
  3. How migration supplies it (fn_iu_create extension vs direct JSON build vs post-create UPDATE)?

4. Opus recommendation — 3 options for GPT/User

Option A — Seed vocab keyed by doc_code

  • Seed: vocab.publication_authority.dieu_35 = DIEU-35 (per publication)
  • Migration sets: identity_profile.publication_authority_ref = 'dieu_35'
  • Pro: granular, traceable per publication
  • Con: creates N vocab entries; dieu_35 as a key is arbitrary

Option B — Derive from tac_publication.owner

  • Migration reads owner from TAC row, injects into identity_profile
  • Pro: uses existing data, no seed needed
  • Con: heterogeneous values (S178-FIX23 is an operator tag, not an authority); no vocab validation; tech debt
  • Seed: vocab.publication_authority.incomex_council = incomex_council
  • Migration sets: identity_profile.publication_authority_ref = 'incomex_council' for all 3 pilots
  • Pro: truthful (all 3 Điều are products of Incomex AI Council governance); 1 vocab entry; simplest; extensible later
  • Con: loses per-publication granularity (acceptable at pilot stage)

Opus leans toward C because:

  • Birth gate only checks non-null (pilot mode) → any valid value unblocks
  • All 3 publications are genuinely council-governed products
  • 1 vocab seed is minimal footprint
  • When enacted workflow exists later, additional vocab entries are trivial to add
  • No tech debt from heterogeneous operator tags

5. What GPT needs to decide

  1. Lock authority value: A, B, or C (or alternative)?
  2. Confirm vocab seed scope: just authority, or also backfill the 12 existing IU rows?
  3. fn_iu_create extension: defer to post-pilot, or include in 5C2 scope?

6. Proposed next steps (after GPT decision)

  1. GPT locks publication_authority_ref_value
  2. Opus patches 5C2 DRAFT → rev1 with locked value + vocab seed step
  3. GPT reviews 5C2 rev1
  4. If approved → Agent dispatches 5C2 (DIEU-35 pilot migration)

7. Status

phase5c2a_probe=PASS_AGENT_COMPLETE_OPUS_REVIEWED
publication_authority_ref_value=PENDING_GPT_DECISION
recommended_option=C_incomex_council
migration_allowed=false
seed_allowed=false
next_action=GPT_LOCK_AUTHORITY_VALUE

Opus Review — Phase 5C2A Probe PASS | 2026-05-12

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-p3d-pack1-phase5c2a-probe-pass-authority-decision-needed-2026-05-12.md