GPT Review — 22-P3 Creation Gateway Design and Next Directive

Date: 2026-05-06
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/design/22-p3-iu-creation-gateway-scope.md

Verdict

P3 Creation Gateway design: direction accepted, but not complete enough for enforcement.

Opus correctly reframed P3 from adapter scope to gateway governance. The two Opus objections are valid and must be incorporated into the next step.

Next step is P3-P0 read-only inspection prompt, not implementation.

Review of Opus objections

Objection 1 — L1 Permission Gate / directus tension

Accepted.

Revoking direct INSERT from directus is not something to assume. It may be impossible or unsafe if:

• directus owns the tables;
• Directus CMS uses the same PG role for internal writes;
• fn_iu_create is SECURITY DEFINER owned by directus;
• table ownership/privilege model is not separated yet.

Therefore L1 in the current phase should be treated as inventory and future role-architecture analysis, not immediate revoke.

Important correction:

• L1 cannot be counted as the main blocker until roles are redesigned.
• L2/L3 are the practical near-term guardrails.
• Any permission isolation would require a separate role architecture pack if P3-P0 evidence supports it.

Objection 2 — L2 set_config marker is not a security boundary

Accepted.

set_config/current_setting guard is a wrong-door blocker / speed bump, not cryptographic or permission-level security. Any session with direct table-write privilege could spoof the setting.

Therefore the design must say clearly:

• L2 reduces accidental bypass and gives a good README error.
• L2 does not stop malicious or privileged bypass.
• L3 detector is mandatory, not optional.
• L1 role separation is the only long-term true PG permission boundary, but it must be designed separately.

Additional issues in current design

1. Trigger guard example still hardcodes too much

Even as pseudo-code, the example contains hardcoded fallback path and hardcoded function name. The design says not to hardcode, but the example may train future agents to copy it.

Patch next design/prompt wording:

• use pseudo-code with policy.readme_path, policy.canonical_function, not literal strings;
• or clearly mark SQL snippet as non-executable illustration only;
• P3-P0 should inspect policy-registry location before any trigger prompt is written.

2. identity_profile->created_via marker needs caution

L3 suggests adding marker into identity_profile. That is potentially okay, but it changes data semantics and may be forgeable. It also requires fn_iu_create modification, which is out of P3 design scope.

P3-P0 should inspect existing audit/provenance options before selecting marker storage:

• identity_profile marker;
• birth_registry metadata if any;
• registry changelog;
• audit table;
• event trigger/log;
• Directus revision/activity tables if available.

Do not assume marker location yet.

3. TAC option T2 is plausible but not proven

Opus recommends controlled import path for TAC. This is plausible, but it rests on claims about TAC domain-specific validation and batch behavior. P3-P0 must inspect TAC code/reports before deciding.

Treat T2 as candidate, not decision.

4. P3-P0 query set is not enough

The 9 SQL queries are a good start but insufficient. P3-P0 must also inspect code/script paths, not only PG:

• TAC/P10 scripts and prompts/reports;
• repository scripts that write information_unit / unit_version;
• Directus permissions/collections if available;
• dot_config / collection_registry fields related to creation policy;
• current health check / orphan detector coverage for IU.

Directive to Opus

Create a P3-P0 read-only inspection prompt, not an enforcement prompt.

Path:

knowledge/dev/laws/dieu44-trien-khai/prompts/22-p3-p0-iu-creation-gateway-inspection-prompt.md

Do not dispatch it after creating; return for GPT/User review.

P3-P0 objective

Collect evidence needed to decide IU Creation Gateway enforcement safely:

1. Who can currently write IU/UV directly?
2. Which code paths currently write IU/UV directly?
3. Can directus be permission-restricted or is it table owner / CMS dependency?
4. Where should policy/README registry live?
5. Can wrong-door trigger guard be added without breaking existing workflows?
6. How should TAC be classified: canonical caller, controlled import, or legacy bypass?
7. What detectors already cover IU bypass/orphan/ghost/invariant drift?

Required inspection sections

§1. PG ownership and privileges

Read-only SQL:

• table owners for information_unit, unit_version;
• table privileges for IU/UV;
• roles with INSERT/UPDATE/DELETE;
• function owners and EXECUTE grants for fn_iu_create, fn_iu_create_plan, P1 helpers;
• whether PUBLIC has any table/function write/execute privileges.

§2. Directus dependency

Inspect read-only:

• Directus collection metadata for information_unit / unit_version;
• Directus permissions/policies if tables exist;
• whether Directus Admin UI is likely able to create rows;
• role mapping: which PG role Directus uses.

Do not modify Directus permissions.

§3. Existing triggers/gates

Read-only SQL:

• all triggers on IU/UV with timing/event/function/enabled state;
• whether adding a new BEFORE INSERT guard would conflict with current L1 birth gate;
• current L1/L2 gate function names and enabled state;
• trigger order if available.

§4. Existing IU rows and provenance clues

Read-only SQL:

• IU count, UV count, birth_iu count;
• created_by distribution;
• identity_profile keys distribution for IU rows;
• pilot rows from P2/P2B;
• any evidence of created_via/source markers already present.

§5. Policy registry location

Inspect existing options:

• dot_config keys under iu_create.%, creation.%, gateway.%;
• collection_registry fields that could hold canonical function/readme path;
• dot_tools / governance registry suitability;
• whether adding a new table would be necessary later.

No writes.

§6. TAC / P10 direct insert inventory

Search code/KB/reports for TAC/P10 IU creation paths:

• exact files/prompts/scripts that insert into information_unit / unit_version;
• whether they use fn_iu_create or direct INSERT;
• what validation they perform;
• batch size/performance assumptions;
• whether they can be migrated to fn_iu_create or need controlled import exemption.

Do not decide T1/T2/T3 before evidence.

§7. Global direct-write inventory

Search repository/filesystem/KB for direct writes:

• INSERT INTO public.information_unit
• INSERT INTO information_unit
• UPDATE public.information_unit
• INSERT INTO public.unit_version
• INSERT INTO unit_version

Classify each occurrence:

• migration;
• test/pilot;
• TAC/import;
• production path;
• stale/historical doc;
• unknown.

§8. Detector / auxiliary coverage

Inspect existing health/orphan/ghost detectors relevant to IU:

• fn_iu_verify_invariants already exists;
• fn_registry_health coverage for IU;
• orphan/ghost jobs or cron;
• whether any detector identifies non-canonical IU creation;
• whether auxiliary/backfill logs can identify fresh-object repair.

§9. Trigger-guard feasibility

Based on evidence, answer:

• Would an L2 BEFORE INSERT guard block P2 fn_iu_create unless function is patched to set marker?
• Would it block TAC/current imports?
• Would it block Directus UI/admin workflows?
• What exempt categories are needed?
• Can marker spoofing be accepted as speed bump only?
• What would be a safe phased rollout?

§10. Risk and recommendation matrix

Report options:

A. Observe-only: no guard, only document policy.
B. L0 policy registry only.
C. L0 + L3 detector first.
D. L0 + L2 trigger guard with controlled exemptions.
E. Full role separation later.

For each, assess:

• breakage risk;
• bypass reduction;
• implementation complexity;
• hardcode risk;
• rollback path;
• readiness.

P3-P0 report path

knowledge/dev/laws/dieu44-trien-khai/reports/22-p3-p0-iu-creation-gateway-inspection-report.md

Hard boundaries

P3-P0 must be read-only.

No:

• DDL;
• DML;
• GRANT/REVOKE;
• trigger creation;
• function change;
• DOT registration;
• adapter implementation;
• cleanup;
• IU row creation.

Expected Opus response now

Opus should create the P3-P0 prompt with the sections above and stop.

No Agent dispatch until GPT/User approves the prompt.

Summary

Opus’s two objections are valid. They refine the gateway design rather than undermine it. The next safe move is not to implement permission revokes or trigger guards; it is to inspect current privileges, Directus dependencies, TAC direct-write paths, policy registry options, and detector coverage.