Incomex AI Portal
KB-768B

GPT Cross-Law Review — Notification/Outbox Universalization Before P3D4C1

10 min read Revision 1
gpt-reviewcross-lawp3d4c1pauseuniversal-outboxnotificationdieu37dieu38dieu39dieu43

GPT Cross-Law Review — Notification/Outbox Universalization Before P3D4C1

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Trigger: User concern that Pack 23/P3D notification design may duplicate or conflict with Điều 37, 38, 39, 43 and constitutional infrastructure if implemented too narrowly for IU.

Verdict

PAUSE P3D4C1 implementation prompt.

Do not continue patching/dispatching P3D4C1 as an iu_notification_*-specific runtime until a cross-law design review is completed.

The User’s concern is valid. Current P3D4C1 direction risks creating a second/parallel event-notification infrastructure for IU while other enacted/draft laws already imply similar needs:

  • Điều 0-G / Birth Registry: universal entity birth tracking.
  • Điều 37: governance agencies, owners/approvers/executors, human checkpoints.
  • Điều 38: Text-as-Code / text units / metadata governance / text-unit birth gate.
  • Điều 39: Knowledge Graph, provenance, temporal state, priority graph, entity linking.
  • Điều 43: System Context Law, context-pack build/verify, DOT registry/config/health, system map.
  • Điều 35/36/28/33/Constitution: DOT governance, collection protocol, display/read-only assembly, PG-native constraints.

Key risk

P3D4C1 currently designs:

  • iu_notification_pending;
  • iu_notification_worker_log;
  • iu_notification_event taxonomy extension;
  • source/batch refs on information_unit;
  • pg_cron worker;
  • Directus board later.

This is technically valid for IU, but it may become duplicated when:

  • Đ43 needs context-pack build/verify notification and health events;
  • Đ0-G/birth_registry needs universal birth events and certification/readiness alerts;
  • Đ38 text units/components need birth/review/version/vector/indexing events;
  • Đ39 KG needs graph/provenance/temporal/constraint events;
  • Đ37 governance agencies need task/checkpoint/escalation notifications.

If we implement IU-only objects now, later choices become bad:

  1. run a second universal system in parallel; or
  2. migrate/dismantle the IU system soon after; or
  3. let duplicate semantics diverge.

Accepted architecture principle

Preserve the performance rule exactly:

AI ghi dữ liệu vào PG thật nhanh
→ hot path chỉ append O(1) vào pending/outbox
→ pg_cron worker sau 90–120s gom notification
→ durable notification/event record
→ Directus/Nuxt chỉ đọc projection

No trigger/function on the AI write path may do COUNT, JOIN, rollup, batch detection, latest_readers, vector work, or derived computation.

But this should be generalized as a universal event/outbox substrate, with IU notification as first consumer/specialization.

Proposed strategic shift

Replace immediate P3D4C1 implementation with a cross-law design pack:

P3D4C0X_UNIVERSAL_EVENT_OUTBOX_AND_NOTIFICATION_ARCHITECTURE_REVIEW

Purpose:

  • design one shared PG-native event/outbox substrate;
  • map IU notification requirements onto it;
  • map Điều 37/38/39/43/Birth Registry needs onto it;
  • define which columns are universal vs domain-specific;
  • decide whether existing iu_notification_* should remain temporary pilot, be renamed/generalized, or be wrapped by a universal view/API;
  • avoid double DOT, double counters, double worker, double Directus board.

Preliminary target shape

Do not commit yet, but likely shape should be:

Universal layer

  • system_event_pending or governance_event_pending — O(1) staging/outbox.
  • system_event or governance_event — durable event history.
  • system_event_read or governance_event_read — per-actor read state.
  • system_event_worker_log — worker observability.
  • fn_system_event_enqueue(...) — O(1) enqueue helper.
  • fn_system_event_worker_tick() — pg_cron worker.
  • v_system_notification_board — generic read projection.

Domain mapping fields

Universal events should carry metadata such as:

  • event_domain / law_scope (iu, birth_registry, context_pack, kg, governance, dot, etc.);
  • event_type;
  • event_stream;
  • entity_species / object_kind;
  • entity_table / entity_ref / ref_id;
  • canonical_address or canonical identity ref;
  • source_document_ref / import_batch_ref where applicable;
  • actor_ref;
  • created_at;
  • safe payload metadata only, if allowed;
  • no body/raw payload/vector/secret by default.

Domain-specific projection

IU can still have:

  • v_iu_notification_board as a filtered view over universal events; or
  • compatibility functions fn_iu_unread, fn_iu_notification_board wrapping universal tables.

But the source runtime should not be a permanently separate IU-only event system unless cross-law review explicitly justifies it.

Law mapping notes

Điều 0-G / Birth Registry

Birth is already universal: every governed entity must have birth record and birth triggers/tooling. Notification birth events should align with birth registry rather than invent a second birth truth.

Điều 37

Governance organization introduces agencies, owners, approvers, executors and human checkpoints. Notification routing/read-state likely needs actor_ref, role_ref, agency_ref, and checkpoint/escalation semantics. IU-only actor strings may be insufficient long term.

Điều 38

Text-as-Code and Text Unit governance make IU/text units the substrate, but the event/outbox mechanism should be reusable for text units, components, metadata governance, review, version and indexing status.

Điều 39

Knowledge Graph requires provenance, temporal events, constraints, priority graph and entity linking. It should consume or project from the universal event stream, not invent parallel graph-event logs unless the KG layer needs a separate derived graph projection.

Điều 43

System Context Law has context-pack build/verify, DOT registry, db map, red zones, health checks, dot_config and multi-DB dispatch. It is especially likely to need build/verify/failure notifications. Since Đ43 has incomplete/schema-blocked areas, implementing IU-only DOT/exposure now increases double-overlap risk.

Directus/Nuxt

Directus remains DOT-driven exposure layer. Nuxt remains display assembly only. Grouping, rollup, routing and read-state must not be solved in Directus UI or Nuxt.

Directive to Opus

Create a design prompt, not implementation:

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

Future report path:

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

Future design note path:

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

Scope:

  1. Read mandatory laws/docs:
    • Constitution;
    • Điều 0-G birth registry law;
    • Điều 28 display law;
    • Điều 33 PG/data/schema law if available;
    • Điều 35 DOT governance;
    • Điều 36 collection protocol;
    • Điều 37 governance organization;
    • Điều 38 Text-as-Code/text unit appendices;
    • Điều 39 KG law;
    • Điều 43 System Context Law + migrations/status/blockers;
    • current Pack 23/P3D notification docs/reports/prompts.
  2. Inventory existing PG tables/functions/triggers/views related to birth, IU notification, context pack, DOT config/health, KG/graph/provenance if visible.
  3. Identify duplicate-risk areas across laws.
  4. Propose universal event/outbox data model and naming.
  5. Decide migration strategy for existing iu_notification_*:
    • keep as pilot/compat layer;
    • wrap via universal view/functions;
    • rename/migrate later;
    • or keep separate with strong justification.
  6. Define universal event taxonomy vs domain-specific taxonomy.
  7. Define hot-path enqueue contract: O(1), append-only, no derived computation.
  8. Define worker contract: pg_cron, 90–120s debounce, stable grouping, advisory lock, logs, idempotence.
  9. Define Directus exposure strategy: one generic board plus domain views, or separate filtered views, DOT-driven only.
  10. Produce go/no-go recommendation for returning to P3D4C1.

Hard boundaries for Opus

  • No implementation.
  • No PG mutation.
  • No Directus mutation.
  • No Nuxt code.
  • No Hermes.
  • No Codex dispatch.
  • No new external scheduler/tool.
  • Do not patch P3D4C1 until cross-law design is reviewed.
  • Do not claim IU board is complete.
  • Do not duplicate Đ43/DOT/context-pack machinery.
  • Do not solve grouping/read-state in Directus or Nuxt.

Required report fields

phase_status=PASS|FAIL|NEEDS_MORE_INVENTORY
cross_law_review_completed=true|false
laws_read=<list>
pg_inventory_depth=KB_ONLY|KB_AND_DB|LIMITED
universal_outbox_recommended=true|false
existing_iu_notification_status=KEEP_TEMP|WRAP_COMPAT|MIGRATE_TO_UNIVERSAL|KEEP_SEPARATE_JUSTIFIED
birth_registry_overlap=LOW|MEDIUM|HIGH
text_unit_overlap=LOW|MEDIUM|HIGH
kg_overlap=LOW|MEDIUM|HIGH
context_pack_d43_overlap=LOW|MEDIUM|HIGH
dot_overlap=LOW|MEDIUM|HIGH
directus_exposure_strategy=GENERIC_BOARD_PLUS_FILTERS|DOMAIN_VIEWS|DEFERRED
hot_path_contract=O1_APPEND_ONLY
worker_contract=PG_CRON_DEBOUNCE_90_120
no_pg_mutation=true
no_directus_mutation=true
no_nuxt_code=true
recommendation=PAUSE_P3D4C1_AND_DESIGN_UNIVERSAL|PATCH_P3D4C1_AS_UNIVERSAL|CONTINUE_IU_SPECIFIC_WITH_JUSTIFICATION|DEFER
next_required_pack=<...>

Current GPT recommendation

recommendation=PAUSE_P3D4C1_AND_DESIGN_UNIVERSAL

P3D4C1 should not be dispatched until this review returns PASS and determines whether IU notification should be generalized or kept as a compatibility layer.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-cross-law-review-notification-outbox-universalization-2026-05-08.md