GPT Review — New IU Notification Logic and Revised P3D4C Directive

Date: 2026-05-08
Reviewer: GPT-5.5 Thinking / Incomex Hội đồng AI

Verdict

User correction is accepted. The previous P3D4C directive must be revised before sending to Opus.

The old direction treated birth/new-IU notification as excluded because P3D2 deliberately excluded version_seq=1 from version_applied events. That was technically true for current runtime, but it is not sufficient for the real operating model.

New business requirement: notification must cover:

1. new information pieces;
2. edited/applied content;
3. new comments.

However, new information pieces created as part of one sliced source document should not spam one notification per piece. The system must eventually support document-level grouping/batch notification.

Accepted user requirements

R1 — Creator implicit self-read applies to birth/new-piece events too

If GPT creates a new information piece, GPT should not receive an unread notification telling GPT to read its own newly created piece.

This matches existing implicit self-read semantics:

• creator/actor sees own event as read;
• other actors can still see it as unread/visible;
• read state remains per actor, not global.

R2 — Notification must include new information pieces

The notification board should eventually include:

• new piece created;
• content updated/applied;
• comment added.

Current P3D2 only has:

• comment_added;
• draft_created;
• version_applied.

P3D2 explicitly excluded birth/new-IU events. That must be treated as a known gap, not as final design.

R3 — Batch/document-level grouping is required for sliced documents

If a long source document is cut into many pieces at once, e.g. 30 IUs, the system should not emit 30 independent user-facing notifications.

Preferred operational logic:

• If multiple new IUs are born from the same source document/import batch, create/show a document-level notification such as:
  • document_imported / document_sliced / document_created_with_pieces;
  • includes piece count and source document reference;
  • individual IU events may remain in durable event history if needed, but user-facing board should group/roll up.
• If one new piece is later added to an existing document, notify that piece normally.

R4 — Downstream workflow needs exact operational state

The notification subsystem should accurately tell later reviewers/agents/users what is happening:

• a single new piece;
• a document imported/sliced into many pieces;
• a comment added;
• content applied/updated.

Implication for P3D4C

Do not continue with P3D4C as if the current notification event set is complete.

P3D4C should not implement a human-facing Directus view that bakes in the incomplete event taxonomy without first documenting the birth/batch gap.

Two acceptable paths:

Path A — Recommended now: create P3D4C as a gap-aware prompt

P3D4C may still be drafted, but it must explicitly:

• expose only the currently active runtime events as Phase 1 current-runtime board;
• document that new_piece / document_imported / batch grouping is missing;
• include a blocker/deferred requirement for a later P3D4D/P3D5 notification birth/batch pack;
• avoid claiming the board is complete for all new content.

This path is acceptable if User wants to get a basic board visible quickly.

Path B — Stronger correctness path: pause P3D4C and first design P3D4C0 birth/batch notification extension

Create a new design prompt before Directus exposure:

23-p3d4c0-new-piece-and-document-batch-notification-design-prompt.md

Goal:

• inspect current birth/import/source document schema;
• determine how to detect single new IU vs document-sliced batch;
• decide event types and grouping rules;
• avoid notification spam;
• preserve implicit self-read.

This path avoids exposing an incomplete human board, but delays UI exposure.

GPT decision

Given User’s concern is about practical operation and avoiding later redesign, GPT chooses Path B unless User explicitly wants the basic incomplete board first.

Reason:

A user-facing board that omits new-piece/document import notifications would fail a core expectation. Adding Directus exposure first may force redesign of the view/DOT immediately afterward.

Revised directive to Opus

Do not proceed directly to P3D4C implementation prompt yet.

Instead, create a design prompt:

knowledge/dev/laws/dieu44-trien-khai/prompts/23-p3d4c0-new-piece-document-batch-notification-design-prompt.md

Report path:

knowledge/dev/laws/dieu44-trien-khai/reports/23-p3d4c0-new-piece-document-batch-notification-design-report.md

P3D4C0 scope

Design/review only. No PG mutation. No Directus mutation. No Nuxt. No Hermes.

P3D4C0 mandatory questions

1. What tables/columns currently identify a new IU birth?

   • information_unit;
   • unit_version.version_seq=1;
   • birth trigger outputs;
   • created_by / actor fields;
   • source document/import metadata if any.

2. Is there already a source document / import batch / parent document concept?

   • canonical address convention;
   • parent/child relationship;
   • source_ref;
   • document_id;
   • batch_id;
   • import job id;
   • publication/document tables if relevant.

3. How can the system distinguish:

   • one new piece added later to an existing document;
   • many new pieces created together from one new document;
   • many unrelated new pieces created separately?

4. What notification event types are needed?

Candidate event taxonomy:

• new_piece_created;
• document_sliced_created or document_imported;
• current existing:
  • comment_added;
  • draft_created;
  • version_applied.

5. Where should grouping occur?

Options:

• PG trigger creates per-piece events, view groups them by source document/batch;
• PG trigger creates one batch/document event and suppresses individual user-facing piece events;
• import/slicing function writes a batch event explicitly;
• hybrid: durable piece events + user-facing rollup view.

GPT leaning: hybrid if schema supports batch/source identifier: durable event history can contain piece-level facts, while Directus-facing view rolls up document-sliced batches.

6. How to avoid spam?

Design rule:

• if N new pieces share same source document/batch within one import operation, board shows one document-level notification with count=N;
• if one piece is later added to an existing document, board shows one piece-level notification;
• creator implicit self-read applies at both piece and document/batch levels.

7. What is the minimum safe implementation path?

Should it be:

• P3D4C0 design only;
• P3D4C1 PG runtime extension for birth/batch events;
• P3D4C2 Directus view/DOT exposure;
• or keep P3D4C view but mark birth/batch as deferred?

8. What are the law boundaries?

• PG owns event detection/grouping runtime.
• Directus exposes resulting metadata.
• Nuxt only displays through existing assembly.
• Do not solve grouping in Nuxt.
• Do not make Directus UI perform grouping logic.

Required P3D4C0 output

Create design note:

knowledge/dev/laws/dieu44-trien-khai/design/23-p3d4c0-new-piece-document-batch-notification-design.md

The note should recommend one of:

• EXTEND_RUNTIME_BEFORE_DIRECTUS_EXPOSURE;
• EXPOSE_CURRENT_RUNTIME_WITH_GAP_DISCLOSED;
• DEFER_BIRTH_BATCH_UNTIL_SOURCE_SCHEMA_READY.

Required report fields

• phase_status;
• birth_notification_gap=CONFIRMED|NOT_CONFIRMED;
• batch_grouping_required=true;
• source_document_identifier=FOUND|NOT_FOUND|UNCLEAR;
• import_batch_identifier=FOUND|NOT_FOUND|UNCLEAR;
• recommended_event_taxonomy=...;
• recommended_grouping_strategy=PIECE_ONLY|DOCUMENT_ROLLUP|HYBRID|DEFERRED;
• creator_implicit_self_read_applies=true;
• no_pg_mutation=true;
• no_directus_mutation=true;
• no_nuxt_code=true;
• next_required_pack.

Hard boundaries

• No implementation.
• No PG mutation.
• No Directus mutation.
• No Nuxt code.
• No Hermes.
• No direct PG from Nuxt.
• No user-facing board claim of completeness until birth/batch logic is resolved or explicitly disclosed.

Summary

The previous P3D4C path was correct for exposing the current runtime, but User has identified a core missing event class: new information pieces, including document-sliced batches. GPT revises the roadmap: first design P3D4C0 birth/batch notification logic, then decide whether to extend runtime before exposing the board through Directus.