GPT Review — Description Policy Investigation Report + Next Directive

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Inputs reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/iu0-description-policy-tiering-runtime-investigation-report.md rev 1
• knowledge/dev/laws/dieu44-trien-khai/reviews/opus-assessment-agent-investigation-description-policy-2026-05-04.md rev 1
• Controlling design: knowledge/dev/laws/dieu44-trien-khai/design/13-iu0-description-policy-tiering-and-pack2b-f6-preflight.md rev 3

Verdict

Agent report: PASS.

Agent completed the read-only investigation correctly:

• Q1–Q11 answered.
• Schema-first guard respected.
• Q11 correctly skipped extra_metadata query because the column is absent.
• 5 options compared.
• No DDL, no write, no trigger/function edit, no IU rows, no Pack 2B.
• HARD STOP respected.

Opus assessment: mostly correct.

The narrowing from 5 options to 2 primary candidates is reasonable:

• Option 2 eliminated: collection_registry.extra_metadata absent; would require DDL anyway and is weaker than a proper column.
• Option 4 eliminated: label/facet granularity is wrong for per-collection policy.
• Option 5 eliminated as standalone: only covers H11b, not H11a or birth guard.
• Option 1 and Option 3 remain candidates.

Important caveat

Do not choose Option 1 or Option 3 yet without resolving the bonus finding:

v_entity_full_classification already has a tier column.

This may be irrelevant, but it is material enough to check before locking the policy-storage design. If the tier column is just an output/display classification, it should not be reused for Description Policy. If it is fed by a configurable registry/view source, it might be usable or at least should be accounted for.

Law / Constitution check

No blocker conflict in investigation or current assessment.

• Điều 20 / NT15: design/investigation before runtime respected.
• Đ43: H11 health behavior is being investigated before modification.
• Đ3/Đ4: no law change yet; proposed tiering aligns with existing architecture-vs-runtime distinction.
• Đ35/Đ36: no DOT/schema mutation yet.
• Đ44: Pack 2B remains blocked; no IU rows created.
• HP NT9: unknown view.tier source must be checked, not guessed.

Strategic recommendation

Proceed with one consolidated design package, not microtasks:

knowledge/dev/laws/dieu44-trien-khai/design/14-description-policy-endpoint-and-execution-design-pack.md

This package should resolve the final option choice and produce an execution-ready design, but not execute.

Required contents of file 14

1. Executive summary

   • Agent investigation PASS.
   • Description Policy Tiering is needed before Pack 2B.
   • Pack 2B remains closed.

2. View-tier source check

   • Include a small read-only evidence section for: SELECT pg_get_viewdef('v_entity_full_classification'::regclass, true);
   • If Opus cannot query runtime directly, prepare one minimal read-only Agent query inside the package and mark it as pre-decision evidence.
   • Answer: what feeds the existing tier column? Is it reusable, irrelevant, or dangerous to overload?

3. Option disposition

   • Option 2: reject.
   • Option 4: reject.
   • Option 5: reject as standalone, maybe keep as transitional/compatibility detail.
   • Option 3: evaluate as no-DDL shortcut.
   • Option 1: evaluate as clean endpoint.
   • Include performance, maintainability, law/health-check implications.

4. Recommended endpoint

   • GPT current leaning: Option 1 as endpoint — explicit description_policy at collection/governance level — because it is self-documenting, queryable, constraintable, Directus-visible, and can be read by H11/fn birth guard.
   • But final recommendation must wait until the view-tier source check confirms there is no better existing source.

5. Candidate policy values

   • required_detailed
   • structured_exempt
   • unclassified
   • Optional: basic_only only if Opus proves it is distinct from structured_exempt and needed.

6. Seed/classification draft

   • Tier A required_detailed list.
   • Tier B structured_exempt list, including information_unit and unit_version.
   • Tier C default/unclassified.
   • Explicit rule: Tier B is exempt only from free-text/detailed description, not from structured metadata.

7. Law/docs amendment plan

   • Đ3: formal Tier A/B/C wording.
   • Đ4: birth guard reads description policy and skips block for structured_exempt.
   • Đ43/H11: H11a/H11b filter by policy.
   • description-enrichment-guide: Tier B out of enrichment scope.
   • Đ44/F6: IU rows need structured metadata/graph, not per-row agent description.

8. Runtime execution design, no execution

   • If Option 1:
     • DDL plan for collection_registry.description_policy or equivalent approved field.
     • Directus field registration plan.
     • Seed/update plan.
     • fn_description_birth_guard amend spec.
     • H11a/H11b SQL amend spec.
     • smoke tests.
     • rollback/compensation.
   • If Option 3:
     • dot_config key design.
     • fn/H11 amend spec.
     • drift risks.

9. Preconditions / hard stops

   • No Pack 2B.
   • No DDL until file 14 is reviewed and User/GPT approve execution.
   • No IU rows.
   • No function/trigger edits.
   • No law patch until wording reviewed.

Directive to Opus/Ocus

Do not execute anything yet.

Create file 14 as above. If runtime view definition is needed and Opus cannot query it directly, include a tiny read-only Agent prompt inside file 14 instead of dispatching immediately. The goal is to avoid choosing Option 1/3 blindly while also avoiding another round of scattered microtasks.

After file 14 is uploaded, GPT/User reviews and decides whether to:

1. request the one read-only viewdef query, if still missing;
2. approve an execution pack for Option 1/3;
3. or ask for law wording changes first.

Current state

• Pack 2A: closed/pass.
• QT-003R: canonical.
• File 13: design/investigation complete.
• Agent runtime investigation: pass.
• Next: file 14 option decision + execution design.
• Pack 2B: still closed until Description Policy and IU birth path F6 are resolved.