Incomex AI Portal
KB-70D2

GPT Review — 23-P3D4C0X Prompt rev1

10 min read Revision 1
gpt-reviewp3d4c0xrev2-requireduniversal-eventnotificationroutingcross-law

GPT Review — 23-P3D4C0X Prompt rev1

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Reviewed: knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0x-universal-event-outbox-notification-architecture-review-prompt.md rev1

Verdict

REV2 REQUIRED — do not dispatch rev1 yet.

Rev1 correctly pivots away from an IU-only notification system toward a universal event/outbox architecture. It has the right law survey, hard boundaries, IU compatibility question, and cross-law direction.

However, the User’s clarified goal is broader than “universal event table”: the real problem is the general mechanism by which PG emits signals/notifications outward to all recipients and surfaces, reusable across all Incomex domains.

Rev1 must be strengthened so the design review covers the full pipeline:

PG fact/event
→ O(1) pending/outbox append
→ worker/debounce/grouping
→ durable event history
→ notification/routing/read-state
→ Directus projection/API
→ Nuxt/display/agent consumption

Accepted in rev1

  • Correctly pauses P3D4C1 IU-specific implementation.
  • Correctly requires cross-law review across HP, Đ0-G, Đ28, Đ35, Đ36, Đ37, Đ38, Đ39, Đ43, Đ44.
  • Correctly identifies IU as first domain, not owner of the infrastructure.
  • Correctly asks about universal pending/outbox, universal read state, worker, domain views, IU migration, Đ43 overlap and Directus strategy.
  • Correct hard boundaries: no PG mutation, no Directus mutation, no Nuxt, no Hermes, no Codex.
  • Correct principle: hot path O(1), PG-native, no duplicate infrastructure.

Required rev2 patches

P1 — Separate “event”, “notification”, “delivery/projection”, and “read-state”

Rev1 currently leans toward a universal event/outbox table. It must explicitly ask Agent to distinguish these layers:

  1. Fact/event layer — durable statement that something happened in PG.
  2. Notification layer — derived/actionable signal for one or more recipients.
  3. Subscription/routing layer — who should receive which classes of events.
  4. Read/ack state layer — per actor/user/agent read or acknowledged status.
  5. Exposure/delivery projection layer — Directus views/API, agent inbox, future UI surfaces.

Do not collapse all layers into one table unless the design justifies it.

P2 — Add recipient/subscriber/routing model

The User asked for “mọi đối tượng nhận được thông báo”. Rev1 mentions actor but not recipient model.

Rev2 must require design answers for:

  • recipients: human user, AI agent, governance agency, role/group, system service;
  • actor vs recipient distinction;
  • creator implicit self-read / self-suppression rule;
  • agency/role based routing from Điều 37;
  • domain subscription rules;
  • escalation targets;
  • opt-in/opt-out or config-based filters where allowed;
  • per-recipient read/ack state.

P3 — Add “PG signal outward” channels without implementing them

The design must cover “PG ra bên ngoài” generally, not only Directus board.

Ask Agent to define channel classes:

  • Directus read projection;
  • Agent inbox / SQL function;
  • Nuxt display projection through Directus;
  • DOT/ops health reports;
  • future webhook/email/chat adapters if ever approved.

Boundary: no external service/tool now. But the architecture should define clean adapter seams so future channels do not create another event system.

P4 — Add source domain taxonomy and event envelope contract

Rev1 candidate columns are good but need a formal “event envelope” contract.

Require Agent to propose:

event_id
event_domain / law_scope
event_type
event_stream / severity / priority
event_subject_type / entity_species
event_subject_ref / entity_ref
event_subject_table
canonical_address or canonical_identity_ref
actor_ref
source_system / source_function / source_dot
source_document_ref / import_batch_ref / correlation_id / causation_id
created_at / occurred_at
payload_classification
safe_payload metadata only

Need explicit policy for:

  • body/raw payload/vector/secrets forbidden by default;
  • correlation/batch/grouping IDs generalized beyond IU;
  • idempotency keys;
  • event schema versioning.

P5 — Add generalized grouping/debounce contract

Rev1 mentions worker design but should ask how grouping works across domains:

  • global vs per-domain debounce window;
  • grouping key strategy: source document, import batch, DOT run id, context-pack build id, workflow id, entity species, agency checkpoint;
  • domain-specific grouping policy stored as PG config/metadata;
  • no grouping in hot path;
  • no grouping in Directus/Nuxt.

P6 — Add lifecycle states for notification/outbox

Universal notification needs states beyond read/unread.

Require assessment of:

  • pending;
  • emitted;
  • delivered/projected;
  • read;
  • acknowledged;
  • resolved;
  • suppressed/self-read;
  • failed/retry/dead-letter if applicable.

Clarify which states are universal and which belong to domain-specific workflows.

P7 — Add compatibility/migration plan for existing P3D1/P3D2 runtime

Rev1 asks A/B/C/D, good. Rev2 must require concrete transition options that do not break current working functions:

  • keep existing iu_notification_event/read as legacy pilot and freeze expansion;
  • dual-write temporarily only if justified and bounded;
  • backfill into universal event table;
  • create compatibility views/functions preserving fn_iu_unread, fn_iu_mark_read, fn_iu_notification_board;
  • deprecate iu_notification_* only after P3D4C2+ validation.

Also require a no-data-loss migration principle.

P8 — Add deeper Điều 43/DOT/context-pack integration questions

Rev1 asks Đ43 overlap generally. Rev2 must specifically ask:

  • should context-pack build/verify/health events be first-class universal events?
  • does dot_config become shared event config or remain DOT-only config?
  • how to avoid duplicate worker/health-check/log tables with Đ43 health checks?
  • how to represent DOT execution pair events without duplicating dot_tools registry?
  • should universal event projections feed Đ43 context-pack sections later?

P9 — Add governance/law ownership decision

Because this is universal infrastructure, it may not belong only under Điều 44 implementation folder.

Rev2 must require Agent to recommend jurisdiction:

  • Is universal event/outbox governed by Đ33/PG, Đ35/DOT, Đ37/governance org, Đ38/TAC, Đ43/system context, Đ44/UOSL, or a new appendix/law?
  • Which law owns schema contract?
  • Which law owns notification routing semantics?
  • Which law owns Directus exposure?
  • Which law owns display?

This is necessary to avoid future jurisdiction conflict.

P10 — Add “not general activity log” boundary

Earlier P3D design explicitly avoided becoming a general activity log. Universalization increases that risk.

Rev2 must ask Agent to define exclusion rules:

  • not every row change is an event;
  • only governance-relevant/significant facts are events;
  • telemetry/logging/metrics remain separate;
  • audit log vs notification event vs task/checkpoint must be distinguished.

P11 — Add required report fields

Add fields:

event_notification_delivery_layers_defined=PASS|FAIL
recipient_model_defined=PASS|FAIL
subscription_routing_model_defined=PASS|FAIL
channel_projection_model_defined=PASS|FAIL
event_envelope_contract_defined=PASS|FAIL
grouping_policy_model_defined=PASS|FAIL
notification_lifecycle_defined=PASS|FAIL
activity_log_boundary_defined=PASS|FAIL
jurisdiction_owner_recommended=<law/appendix>
existing_p3d_runtime_transition=FREEZE_AND_WRAP|BACKFILL_AND_WRAP|MIGRATE|KEEP_SEPARATE_JUSTIFIED
no_data_loss_principle=true
p3d4c1_status=PAUSED_PENDING_UNIVERSAL_DESIGN

P12 — Add recommendation options aligned with universalization

Rev1 options are good but should include:

  • UNIVERSAL_ARCHITECTURE_FIRST — design universal, then implementation prompt;
  • UNIVERSAL_CORE_WITH_IU_COMPAT_FIRST_CONSUMER — build universal core, wrap current IU runtime as first consumer/compat layer;
  • UNIVERSAL_EVENT_ONLY_NOTIFICATION_LATER — event substrate now, routing/notification later;
  • NEEDS_LAW_APPENDIX_BEFORE_IMPLEMENTATION — pause implementation until ownership/jurisdiction is amended;
  • IU_SPECIFIC_EXCEPTION_DENIED unless strong justification exists.

Directive to Opus

Patch the prompt to rev2 at:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0x-universal-event-outbox-notification-architecture-review-prompt.md

Do not dispatch after patch. Return for GPT/User review.

Hard boundaries unchanged

  • No implementation during prompt patch.
  • No PG mutation.
  • No Directus mutation.
  • No Nuxt code.
  • No Hermes.
  • No Codex dispatch.
  • No new external scheduler/tool.
  • Do not resume P3D4C1 until P3D4C0X is approved and executed.

Summary

Rev1 is directionally correct but still too narrow: it designs a universal event/outbox, while the User is asking for a universal PG-to-outside notification/signal architecture. Rev2 must force the design to cover event, notification, recipient routing, read/ack state, delivery projections, channel adapters, ownership, and migration of existing IU runtime.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-review-23-p3d4c0x-prompt-rev1-2026-05-08.md