GPT Review — 22-P3-P0 Results and P3-P1 Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed:

• knowledge/dev/laws/dieu44-trien-khai/reports/22-p3-p0-iu-creation-gateway-inspection-report.md
• knowledge/dev/laws/dieu44-trien-khai/reviews/opus-review-22-p3-p0-inspection-results-2026-05-06.md

Verdict

22-P3-P0 PASS for core evidence.

inspection_status=PARTIAL is acceptable because the 3 failed queries were optional auxiliary/stale-schema queries. Core evidence for gateway decision is complete enough.

No Agent rerun is needed.

Accepted findings

F1 — TAC/P10 is out of IU gateway scope

Accepted. TAC/P10 writes target sandbox_tac.tac_*, not public.information_unit / public.unit_version.

Therefore TAC exemption/migration is removed from immediate P3 gateway scope.

F2 — IU/UV are not Directus collections

Accepted. information_unit / unit_version are not in directus_collections, but Directus permissions reference them for Agent/AI Agent create/read paths.

Implication: Studio UI native collection create form is not the main risk. Directus REST/GraphQL write is still a possible direct-write surface through PG role directus.

F3 — Zero production direct-write callers found

Accepted with normal caveat: the search covered KB and searched filesystem roots, but cannot prove future/ad-hoc CLI never happens. However, for current design this is enough to say enforcement breakage risk is low.

F4 — fn_iu_create does not set app.canonical_writer

Accepted. This is the key sequencing dependency. Any trigger guard requiring the marker would brick the canonical path unless fn_iu_create is patched first.

F5 — UV has zero triggers

Accepted. UV guard is feasible from an ordering standpoint, but it must be designed carefully because fn_iu_create inserts UV too. The same canonical marker should cover IU and UV creation within the function transaction.

Decisions on Opus’s 3 questions

Q1 — Directus REST write path: block or exempt?

Decision: block by default after gateway enforcement. Do not exempt Directus REST direct-create as normal path.

Rationale:

• The whole point is to stop direct table creation and force canonical creation.
• Directus REST direct POST to /items/information_unit would recreate the wrong-door problem.
• If a future Directus API is needed, it should be a thin action/flow/endpoint that calls fn_iu_create, not raw table create.
• Temporary migration/import exemptions can exist later, but they must be explicit, named, narrow, audited, and time-limited.

Q2 — Can P3-P1 combine L0 policy + fn_iu_create patch?

Decision: yes, but only because P3-P1 remains tightly scoped and includes no trigger guard.

P3-P1 may do two things:

1. Seed L0 policy keys in dot_config.
2. Patch fn_iu_create to set the canonical-writer marker.

This is acceptable because both are prerequisites for trigger guard and neither enforces blocking behavior by itself.

However, P3-P1 must not create trigger guards, revoke permissions, change Directus permissions, or create detectors.

Q3 — UV guard now or later?

Decision: design for both IU and UV, but implement guard in a later P3-P2 only after P3-P1 proves marker works.

Reasoning:

• If only IU guard exists, an actor might insert/update UV directly and create inconsistent version state.
• Since fn_iu_create writes both IU and UV in one transaction, a transaction-local canonical marker can authorize both.
• But adding guards is enforcement. It belongs in P3-P2, not P3-P1.

Next step: P3-P1 prompt

Opus should create a P3-P1 execution prompt for GPT/User review. Do not dispatch after creating.

Prompt path:

knowledge/dev/laws/dieu44-trien-khai/prompts/22-p3-p1-iu-gateway-policy-and-canonical-marker-prompt.md

Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/22-p3-p1-iu-gateway-policy-and-canonical-marker-report.md

P3-P1 objective

Prepare the system for future trigger guard without enforcing the guard yet.

P3-P1 must:

1. Add L0 policy keys to dot_config idempotently.
2. Patch public.fn_iu_create(...) so it sets a transaction-local canonical writer marker before any IU/UV insert.
3. Verify that fn_iu_create still creates a pilot IU successfully.
4. Verify that the marker is local to the transaction and does not leak into the session after transaction.
5. Verify existing permissions remain unchanged.
6. Verify no trigger guard exists yet and no direct writes are blocked in P3-P1.

Required P3-P1 details

§1. Preflight

Read and record:

• exact fn_iu_create signature and md5/source hash before;
• dot_config existing gateway keys;
• current triggers on IU/UV;
• count of IU/UV/birth before;
• effective privileges snapshot from P3-P0 or re-query minimal current snapshot;
• verify fn_iu_create does not already set app.canonical_writer.

If fn_iu_create already sets marker, do not double-patch; report idempotent state and proceed to policy-key verification only.

§2. L0 policy keys

Use INSERT ... ON CONFLICT (key) DO UPDATE or equivalent if dot_config.key is unique. If uniqueness is not guaranteed, preflight must inspect and STOP if duplicate keys exist.

Suggested keys, but Agent must check existing dot_config convention and keep values text:

• iu_create.gateway.mode = prepared
• iu_create.gateway.canonical_function = public.fn_iu_create(text,text,text,text,text,text,text,text,uuid)
• iu_create.gateway.plan_function = public.fn_iu_create_plan(text,text,text,text,text,text,text,text,uuid)
• iu_create.gateway.marker_key = app.canonical_writer
• iu_create.gateway.marker_value = fn_iu_create
• iu_create.gateway.direct_insert_policy = block_after_guard
• iu_create.gateway.readme_path = knowledge/dev/laws/dieu44-trien-khai/readme/iu-create-gateway-readme.md
• iu_create.gateway.exempt_policy = none_active

No hardcoded trigger message is created in P3-P1; keys are policy registry only.

§3. Patch fn_iu_create safely

Preferred approach:

• Create a new function body with the same exact signature using CREATE OR REPLACE FUNCTION only if approved for this patch phase.
• Since P2 prohibited CREATE OR REPLACE during initial creation, P3-P1 is a controlled patch phase and may use CREATE OR REPLACE FUNCTION only for public.fn_iu_create exact signature, not helpers or other functions.
• Preserve owner, SECURITY DEFINER, volatility, search_path, return shape, invariant checks, unique guard, and all P2 behavior.

Required code behavior:

PERFORM set_config('app.canonical_writer', 'fn_iu_create', true);

This must occur before any INSERT/UPDATE to information_unit or unit_version.

Use transaction-local true so marker does not leak after transaction.

§4. Tests

Create one new dynamic pilot via fn_iu_create, e.g. pilot.p3.p1.<timestamp>.<hex>.

Verify:

• pilot IU exists exactly once;
• pilot UV exists exactly once;
• birth row exists exactly once;
• fn_iu_verify_invariants(pilot_address)->>'all_pass' = true;
• idempotent re-call returns exists_complete;
• no duplicate IU/UV/birth;
• session marker after transaction is not set: current_setting('app.canonical_writer', true) is null/empty.

Do not cleanup pilot.

§5. Permission and trigger safety

Verify:

• no new trigger guards created;
• trigger count on IU/UV unchanged;
• PUBLIC grants remain absent;
• directus EXECUTE remains available;
• table privileges unchanged from preflight.

§6. Report

Report must include:

• policy keys before/after;
• fn_iu_create hash before/after;
• proof marker string exists in function source after patch;
• pilot address and invariant JSON;
• marker leak test result;
• trigger count unchanged;
• permission snapshot unchanged;
• hard boundaries honored.

§7. Failure handling

If patch or tests fail:

• rollback transaction if still inside transaction;
• upload partial report;
• do not retry;
• do not create trigger guard;
• do not cleanup without approval.

Hard boundaries for P3-P1

• No trigger guard creation.
• No GRANT/REVOKE.
• No Directus permission changes.
• No role separation.
• No detector implementation.
• No DOT registration.
• No adapter implementation.
• No cleanup of P2/P3 pilots.
• No Pack 2C.

Clarification on CREATE OR REPLACE

Unlike P2 initial creation, P3-P1 is a controlled patch of an existing function. CREATE OR REPLACE FUNCTION public.fn_iu_create(exact signature) is acceptable only if the prompt includes full function body, preserves all P2 semantics, and verifies hash/behavior after patch.

No broad replace, no helper replace, no copying from old revisions.

Expected Opus response

Opus should create the P3-P1 prompt at the path above and stop for GPT/User review.

Do not dispatch Agent yet.

Summary

P3-P0 confirmed the gateway can be introduced safely, but the first mutation should be preparatory only: policy keys + canonical marker in fn_iu_create. Enforcement triggers come later in P3-P2 after marker behavior is proven.