Incomex AI Portal
KB-2ECA

GPT Review — File 14 rev3 Description Policy Write Path Corrected

6 min read Revision 1
gpt-reviewfile14-rev3description-policywrite-pathentity-enrichmentiu-0execution-pack-next

GPT Review — File 14 rev3 Description Policy Write Path Corrected

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/14-description-policy-endpoint-and-execution-design-pack.md rev 3

Verdict

PASS — conceptual correction accepted. Still no runtime execution approval.

File 14 rev3 now correctly states the deployed description write path:

  • Source entity description columns exist and are the current place to write descriptions.
  • Gemini/Agent enrichment has used Directus REST API to write descriptions directly to source entities.
  • Provenance can move from PROV-DOT to PROV-AI.
  • entity_enrichment is a planned master/mirror upgrade, not the current deployed write path.
  • description_policy is a routing/enforcement layer, not a content store.

This resolves User's concern.

What is now correct

The model is now four-layered and accurate:

  1. Current deployed direct source-entity description write path.
  2. Future planned entity_enrichment master/mirror system, currently absent.
  3. description_policy as routing/enforcement policy.
  4. IU structured-exempt rows using structured metadata instead of per-row free-text description.

Law / Constitution check

No blocker conflict in the design direction.

  • Đ3: source-entity description and enrichment guide remain valid today; future §2.7 enrichment master is recognized separately.
  • Đ4: birth guard behavior remains a design target, not changed yet.
  • Đ43/H11: policy filtering is still needed before Pack 2B.
  • Đ35/Đ36: no DOT/runtime mutation yet.
  • Đ44: Pack 2B remains closed.
  • Điều 20/NT15: design-before-execution respected.

Decision on option direction

GPT accepts Option 1 as the preferred policy endpoint direction, not yet as execution approval:

  • collection_registry.description_policy for policy/routing.
  • Current direct write path remains source entity description columns.
  • Future entity_enrichment master remains separate and can consume description_policy later.

Option 3 (dot_config JSON) remains a fallback if User rejects DDL, but it is not preferred.

Important caution before execution

File 14 rev3 is still a design pack, not an execution prompt. Before any runtime change, Opus must create a concrete execution pack that includes exact SQL, rollback, smoke tests, law/doc patch plan, and STOP conditions.

Directive to Opus/Ocus

Prepare one consolidated execution design pack, not runtime execution:

knowledge/dev/laws/dieu44-trien-khai/design/15-description-policy-option1-execution-pack.md

Purpose: turn file 14 rev3 into an exact, reviewable implementation pack for Option 1. Do not execute.

Required contents:

  1. Inputs and controlling docs:

    • file 14 rev3;
    • agent investigation report;
    • entity_enrichment preflight report;
    • Đ3/Đ4/Đ43/H11 docs;
    • description-enrichment-guide.

  2. Final scope:

    • add policy field to collection_registry;
    • seed policy values;
    • amend fn_description_birth_guard spec;
    • amend H11a/H11b query specs;
    • guide/law wording drafts;
    • no Pack 2B/IU rows.

  3. Exact DDL proposal:

    • ALTER TABLE collection_registry ADD COLUMN description_policy ...;
    • CHECK constraint;
    • Directus field registration method must use legal DOT/tool if one exists, or STOP if unclear.

  4. Seed table:

    • required_detailed collections;
    • structured_exempt collections;
    • unclassified default;
    • include rationale per group;
    • verify that listed collections exist before update.

  5. Function amendment spec:

    • exact pg_get_functiondef current-source capture step;
    • exact intended diff/pseudocode;
    • Tier B early return only for structured_exempt;
    • behavior for required_detailed unchanged;
    • behavior for unclassified must be explicit. Suggested: do not exempt; warn/discover, not silently pass.

  6. H11 amendment spec:

    • H11a filters required_detailed only OR handles unclassified separately;
    • H11b behavior after policy;
    • baseline before/after comparison.

  7. Current write path compatibility:

    • Gemini/Agent direct source-entity updates remain valid;
    • description_policy only affects routing/health/birth guard;
    • no claim that enrichment master is deployed.

  8. Entity Enrichment Master compatibility:

    • future entity_enrichment can consume description_policy;
    • no deploy of entity_enrichment in this pack.

  9. Smoke tests:

    • DDL column visible;
    • seed counts;
    • H11 baseline before/after;
    • insert/update behavior for Tier A/Tier B test cases, with rollback/cleanup;
    • verify no IU rows created.

  10. Rollback/compensation:

  • revert function;
  • revert H11 query docs;
  • drop column if needed;
  • rollback Directus field registration if added;
  • preserve audit trail.
  1. STOP conditions:
  • existing description_policy column already exists with incompatible semantics;
  • Directus registration mechanism unclear;
  • function source differs from expected;
  • H11 executor differs from KB query docs;
  • any write path requires raw SQL where DOT/legal tool exists;
  • unexpected IU rows or Pack 2B activity.
  1. Decision request:
  • User/GPT approve execution pack or revise;
  • do not dispatch Claude Code until approved.

Hard boundaries

  • Do not execute DDL.
  • Do not patch laws/docs yet.
  • Do not edit function/trigger.
  • Do not create IU rows.
  • Do not open Pack 2B.
  • Do not deploy entity_enrichment.

Next after file 15

GPT/User review file 15. If approved, then and only then prepare a Claude Code execution prompt.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-file14-rev3-description-policy-writepath-corrected-2026-05-04.md