KB-1F24

GPT Reconsideration — Pause P3D4C1U rev4 for Immediate/Delayed Hybrid Signal Model

8 min read Revision 1
gpt-reviewp3d4c1upauserev5-requiredhybridimmediatedelayedpg-cronidle-load

GPT Reconsideration — Pause P3D4C1U rev4 for Immediate/Delayed Hybrid Signal Model

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI
Trigger: User + Opus concern that fixed pg_cron polling every 2 minutes creates avoidable idle load on a small VPS.

Verdict

PAUSE / SUPERSEDE prior final approval of P3D4C1U rev4.

The previous approval was correct on schema consistency and production-safety, but the User’s operational concern is valid: a pure deferred-worker model that wakes every ~2 minutes creates unnecessary idle work when most events are immediate single events.

P3D4C1U must be patched before dispatch.

Architectural correction

Adopt a universal two-lane PG-to-outside signal model:

Lane A — IMMEDIATE
PG trigger/function emits durable event_outbox row directly, O(1).
Use for single governance-significant events that do not require debounce/grouping.
Examples: system issue opened/resolved/archived, comment_added, draft_created, approval_requested, dot_failed, health_alert.

Lane B — DELAYED / DEBOUNCED
PG trigger/function appends O(1) row to event_pending.
Worker processes only delayed/groupable rows after domain/event delay window.
Use for batch/import/rollup/noise-prone signals.
Examples: IU document import batch, many entity births from one batch, context-pack grouped build events if needed.

The hot path remains O(1) in both lanes:

  • Immediate lane: one durable insert into event_outbox plus optional implicit-self read insert if accepted.
  • Delayed lane: one staging insert into event_pending.

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

Why this is better than pure 2-minute polling

Pure cron polling every 2 minutes means ~720 scheduled runs/day, most likely empty on a small VPS. That is structurally wasteful.

The hybrid model reduces latency and idle load:

  • common single events emit immediately;
  • rare batch/noisy events defer into pending;
  • worker can run less frequently or be conditionally scheduled only when there are pending delayed events;
  • Directus/Nuxt still read projection only.

Required P3D4C1U rev5 change

Patch the prompt from “all events go through event_pending + worker” to “route by delivery lane”.

1. Add delivery_lane to event_type_registry

Candidate fields:

delivery_lane text CHECK IN ('immediate','delayed')
delay_seconds int NULL  -- allowed only for delayed, e.g. 90/120/180
grouping_policy text NULL  -- e.g. none, correlation_rollup, domain_batch
active boolean

For PoC system_issues:

issue_opened       immediate
issue_resolved     immediate
issue_archived     immediate
red_zone_violation delayed or inactive/deferred, as previously decided

Preferred for this PoC: keep red_zone_violation inactive/deferred.

2. Immediate capture for system_issues

fn_event_capture_system_issues() should emit directly into event_outbox, not event_pending, for the 3 active PoC event types.

It must:

  • validate via registry trigger;
  • insert only safe metadata payload;
  • use actual system_issues columns from preflight;
  • remain O(1);
  • use idempotent ON CONFLICT DO NOTHING or deterministic unique key;
  • insert implicit-self read if the explicit-row policy is retained;
  • never perform COUNT/JOIN/rollup/grouping.

3. Keep event_pending and worker, but only for delayed lane

Do not remove delayed infrastructure completely. Keep it because it is needed for universal batch/debounce later.

But in P3D4C1U PoC:

  • event_pending can be created as universal delayed lane infrastructure;
  • no system_issues active event should require pending;
  • worker may be implemented but must not be scheduled every 2 minutes by default unless delayed lane is actually enabled and pending rows exist;
  • acceptable alternatives:
    • create worker function but do not schedule cron in P3D4C1U; mark worker_schedule=DEFERRED_UNTIL_DELAYED_EVENT_TYPE_ACTIVE;
    • or schedule less frequently and only if there is at least one active delayed event type, e.g. every 5 minutes, but this is less preferred for the PoC;
    • or use a PG-native self-scheduling/conditional pattern if simple and safe, but no external scheduler.

Preferred for P3D4C1U: create delayed-lane schema/function only if needed, but do not schedule cron until a delayed event type is active. Since system_issues PoC is immediate-only, no idle polling is needed.

4. dot_config keys must distinguish lane behavior

Use namespaced keys such as:

event.global.default_delay_seconds = 120
event.system.issue_opened.delivery_lane = immediate
event.system.issue_resolved.delivery_lane = immediate
event.system.issue_archived.delivery_lane = immediate
event.worker.enabled = false  -- until delayed event types are active

Or prefer registry columns over config keys for stable event-type behavior. Avoid duplicating source of truth between registry and config.

5. Tests must change

Current T3/T6 assume system_issues -> pending -> worker -> event_outbox. Rev5 tests should instead prove:

  • insert tagged system_issues creates event_outbox immediately;
  • resolved/archived status transitions create event_outbox immediately;
  • non-status update creates no event;
  • no pending row is created for immediate event types;
  • worker is not scheduled when no active delayed event types exist, or scheduled status is explicitly deferred;
  • delayed-lane function/table exists only if included and does not run idle polling;
  • implicit self-read / mark-read works;
  • IU runtime unchanged.

6. Worker/cron report fields must change

Replace mandatory worker schedule fields with lane-aware fields:

delivery_lanes_defined=PASS|FAIL
system_issue_events_lane=IMMEDIATE
immediate_events_insert_outbox_directly=true
system_issue_pending_rows_created=0
worker_required_for_poc=false
worker_function_created=PASS|DEFERRED_WITH_REASON
worker_cron_scheduled=NO_NOT_REQUIRED_FOR_IMMEDIATE_POC|PASS|FAIL|ALREADY_PRESENT
idle_polling_avoided=true
delayed_lane_status=SCHEMA_ONLY|DEFERRED|ACTIVE

7. Next-pack naming

If P3D4C1U rev5 PASS and implementation succeeds, next remains:

P3D4C2U_DIRECTUS_DOT_READONLY_EXPOSURE_PROMPT_REVIEW

Directive to Opus

Patch:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c1u-universal-core-implementation-prompt.md

to rev5.

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

Hard boundaries unchanged

  • No PG mutation during prompt patch.
  • No Directus mutation.
  • No Nuxt code.
  • No Hermes/Codex dispatch.
  • No external scheduler/tool/service.
  • No change to existing iu_notification_* runtime.
  • No old IU-specific P3D4C1 resume.
  • No body/raw payload/vector/secret/personal data exposure.
  • No activity-log creep.

Summary

The two-lane model is a better universal design for Incomex: immediate O(1) durable events for common single signals; delayed pending/worker only for events that truly need debounce/grouping. This avoids unnecessary idle pg_cron polling while preserving the universal event substrate and hot-path constraints.

Back to Knowledge Hub knowledge/dev/laws/dieu44-trien-khai/reviews/gpt-reconsideration-23-p3d4c1u-rev4-pause-for-immediate-delayed-hybrid-2026-05-08.md