GPT Design Reconsideration — Pack 23 Natural Upsert Router

Date: 2026-05-07
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Context: User raised an operational concern: AI/Agents cannot be expected to remember create-vs-edit-vs-apply rules across sessions.

Verdict

The current Pack 23 design is technically correct, but the agent-facing interface is still too rule-dependent.

We should not rely on AI/Agents remembering:

• new IU → fn_iu_create;
• existing IU edit → fn_iu_create_edit_draft or fn_iu_edit;
• review/apply → fn_iu_apply_edit_draft;
• direct writes forbidden;
• draft visibility rules.

This is too much for stateless agents. The system must route intent automatically.

Design adjustment needed

Add a future-facing natural command layer, likely after P3C2 PASS but before broad operational use:

Proposed pack: P3C3 — IU Natural Upsert/Edit Router

Function concept:

fn_iu_save(
  p_address text,
  p_body text,
  p_actor text,
  p_title text DEFAULT NULL,
  p_reason text DEFAULT NULL,
  p_mode text DEFAULT 'auto'
) RETURNS jsonb

Agent-facing rule:

If you want to save content for an IU address, call fn_iu_save(...).

System behavior:

1. If address does not exist:

   • create new IU via fn_iu_create;
   • this is the first official version;
   • return created_official.

2. If address exists:

   • do not overwrite official content directly;
   • create edit draft;
   • then either:
     • if policy = auto_apply and mode allows → apply;
     • if policy = require_review or mode='draft' → return draft for review.

3. If exact same content:

   • return no_change.

4. If ambiguous or unsafe:

   • return self-guiding status with guidance and next_action.

Why this is needed

AI/Agents are stateless. Even if we write perfect README, after a session switch they forget. The safe design is not “remember the rule,” but “call the one obvious command and let PG route it.”

The router becomes the AI-facing front door. Lower-level functions remain for advanced/reviewer workflows.

Does current P3C2 need to be changed now?

P3C2 approved prompt creates fn_iu_apply_edit_draft and fn_iu_edit. It is still needed.

But we should reconsider whether fn_iu_edit should remain default auto_apply after P3C2, or whether policy should move toward require_review for important IUs.

Immediate recommendation:

• Do not cancel P3C2 yet if already dispatched? If not dispatched, Opus should review whether fn_iu_edit should default to require_review rather than auto_apply before execution.
• In any case, add P3C3 router to roadmap before broad Agent use.

Better UX contract

Agent should only need this mental model:

save content → fn_iu_save(address, body, actor)
comment → fn_iu_comment(address, actor, comment)
review/apply pending draft → fn_iu_apply_edit_draft(draft_id, actor)

Even better after P3D:

get work inbox → notification/update/comment queue
act on item → function suggested by item.next_action

Important policy distinction

• First creation can be official immediately because there is no prior official version to corrupt.
• Edits to existing official content should normally create a draft and require explicit apply unless policy allows auto_apply.
• Drafts are not visible to official readers until applied.

Directive to Opus for next review

Before dispatching P3C2 or immediately after P3C2 report, Opus should evaluate:

1. Should iu_edit.policy.default_mode stay auto_apply, or should we switch default to require_review before real use?
2. Should fn_iu_edit be presented as an internal convenience wrapper, while AI-facing docs point to future fn_iu_save?
3. Should we add P3C3 Natural Router to roadmap before P3D notification outbox, or after P3D?
4. What is the minimal PG-native implementation of fn_iu_save reusing existing functions without new schema?

Summary

The underlying functions are correct as building blocks. The missing layer is a natural router that prevents agents from needing to remember create-vs-edit rules. This is essential for stable multi-agent operation.