GPT Root Cause — Context Governance Gap after Pack 2A Confusion

Date: 2026-05-04 Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI Trigger: User asked why agents did not use Đ43/context graph and why context transfer became confused at tiny system scale.

Evidence checked

• knowledge/dev/laws/dieu43-system-context-law.md rev 51
• Đ43 §3.1: “Mọi AI/agent phiên mới BẮT BUỘC đọc PROJECT_MAP.md trước hành động.”
• Đ43 §9.1/§9.2: Description Coverage, v_entity_full_classification, mapping table → entity type → format description, provenance, H11a/H11b.
• Đ43 §16: links to Đ0-G, Đ35, Đ36, Đ38, etc.
• Context-pack search results showing PROJECT_MAP, LAWS_INDEX, DOT_REGISTRY, DB_MAP exist across builds.
• Recent Pack 2A reviews and reports.

Root cause conclusion

The core gap is not absence of laws or documents. The system has laws and a context graph. The gap is non-enforcement of context acquisition as a hard gate.

Agents and GPT treated Agent Data search as optional/manual research, not as a mandatory executable preflight governed by Đ43. This allowed local prompt reasoning to outrun the system graph.

Specific failures

1. Đ43 PROJECT_MAP pre-read not enforced

Đ43 already mandates that every new AI/agent session must read PROJECT_MAP.md before action. In Pack 2A we did not enforce this at the start of GPT/Opus/Claude Code workflow. The result: we rediscovered laws/tools by conversation instead of querying the system map first.

2. Law-domain resolver missing in execution packs

Before Pack 2A, no mandatory step asked: “This action belongs to which specialty laws and which DOT tools?” Therefore metadata registration was incorrectly treated as harmless INSERT before Đ4/Đ35/Đ36 were reloaded.

3. Context graph exists but is not promoted to controlling input

Đ43 has PROJECT_MAP, LAWS_INDEX, DOT_REGISTRY, DB_MAP, etc. But prompts did not require agents to load these sections first or cite them in their design. The graph was available but not part of the gate.

4. Description governance already existed in Đ43/Đ3/Đ4 but was not surfaced

Đ43 §9.1/§9.2 already contains Description Coverage, H11a/H11b, v_entity_full_classification, and mapping table to description formats. We initially reasoned from local memory and later rediscovered Description Law. That is a context-gate failure.

5. Review checklist was human-memory based

GPT review relied too much on “remember relevant laws” rather than an explicit checklist: Đ43 graph → law resolver → DOT resolver → runtime evidence → design. Memory does not scale.

6. Design docs lacked a mandatory ‘Graph/Context Evidence’ section

File 11/12 style required legal basis, but did not require evidence from PROJECT_MAP/LAWS_INDEX/DOT_REGISTRY/DB_MAP. Legal basis became a list, not a graph-backed dependency resolution.

7. Safety barriers are partial

Some barriers exist: DOT tools, trigger guard, HC-REG, description guard. They protect runtime writes partially, but do not yet protect the planning layer from choosing a wrong path. The planning layer still needs graph preflight.

Why this becomes catastrophic at 10% scale

At 0.01% scale, a human/User can still notice drift. At 10% scale, local memory and manual search will fail because:

• number of laws grows;
• tool variants grow;
• registry conventions drift;
• hidden dependencies multiply;
• session handoff loses nuance;
• agents will optimize locally unless forced to read the graph.

Without a hard graph preflight, the system will become legally rich but operationally chaotic.

Required structural fix

Introduce a mandatory preflight gate before any design/execution package:

Context Graph Gate (CGG)

For every non-trivial action, the agent must load and cite:

1. Latest Đ43 context pack:
   • PROJECT_MAP.md
   • LAWS_INDEX.md
   • DOT_REGISTRY.md
   • DB_MAP.md
   • RED_ZONES.md
2. Domain law resolver:
   • Which laws govern the action?
   • Which tools/DOT are mandated?
   • Which health checks/guards exist?
3. Runtime evidence:
   • Actual table/tool/function/config state.
4. Unknowns:
   • Anything not resolved becomes read-only discovery, not design assumption.

Immediate directive recommendation

Before continuing Pack 2A file 12 rev2, Opus should create a small but structural procedure note:

knowledge/dev/laws/dieu43-phu-luc-context-graph-gate-procedure.md

or, if we want to keep it within IU-0 implementation first:

knowledge/dev/laws/dieu44-trien-khai/design/12b-context-graph-gate-for-pack2a.md

Content should define the CGG checklist and apply it immediately to Pack 2A:

• load latest context pack;
• identify relevant laws Đ2/Đ3/Đ4/Đ20/Đ35/Đ36/Đ43/Đ44;
• identify relevant DOT tools from DOT_REGISTRY;
• identify relevant DB tables/guards from DB_MAP;
• identify red zones;
• then patch file 12 rev2.

Recommendation

Do not treat this as another micro-patch. Fold it into the next Opus task as a single package:

1. 12a Description/Birth Contract Decision Note.
2. 12b Context Graph Gate application for Pack 2A.
3. File 12 rev2 patch.

After this, GPT review must check that file 12 rev2 includes a Context Graph Evidence section before approving dispatch.

Final root cause sentence

The main hole is not that the system lacks law or graph. The hole is that the graph is advisory, not yet a compulsory gate in every planning/execution workflow.