Prompt — IU-Centered 4 Mothers + Event Foundation Requirement Rev2

Date: 2026-05-27 Author: GPT Council via Web Connector fallback Target agent: Claude Code / Architecture Agent Mode: DOCUMENT ONLY Production mutation: FORBIDDEN Goal: Complete official requirement brief rev2 before master design approval.

0. Mission

You must revise the current requirement brief into an official Rev2 requirement package for:

IU-Centered 4 Mothers + Event Foundation

Current rev1 is accepted only as baseline. It is not yet approved for implementation.

The user clarified that the center of the system is not workflow, not task, not queue, and not UI. The center is the Information Unit / miếng thông tin.

A workflow of 2 steps or 500 steps must be assembled from IU-backed step bricks or IU bundles. Build each information/process brick once, reuse many times. MOW/MOT/MOIT/MOUT are factories around IU, not separate systems that merely attach IU as a description.

Your task is to complete the official requirement document first. Do not write final design as if approved. You may add design implications, but the output must be requirement-first.

1. Required sources to read before writing

Read and reconcile all of the following:

KB documents

knowledge/dev/requirements/iu-mow-mot-event-foundation-requirements.md
knowledge/dev/design/iu-mow-mot-event-foundation-design.md
knowledge/dev/design/law-extraction-plan-application-process-workflow-task.md
knowledge/dev/implementation/iu-4mothers-event-foundation-roadmap.md
knowledge/dev/design/assembly-first-open-source-integration-critique.md
knowledge/dev/reports/architecture/iu-4mothers-event-foundation-requirement-design-2026-05-27.md
knowledge/dev/reports/architecture/iu-4mothers-event-foundation-council-review-gpt-2026-05-27.md
knowledge/dev/reports/architecture/iu-4mothers-event-foundation-council-review-gpt-addendum-2026-05-27.md
knowledge/dev/reports/architecture/iu-4mothers-event-foundation-gpt-recheck-after-drive-upload-2026-05-27.md
knowledge/dev/requirements/iu-centered-4mothers-event-design-patch-instruction-2026-05-27.md

Uploaded / Drive-derived content

Read the current uploaded/Drive-derived files provided by user:

4 mẹ mở rộng.txt
Bắt sự kiện của PG(3).docx

If Google Drive direct access fails, explicitly say so and use uploaded files as authoritative accessible copies.

Laws / principles

Read relevant laws and cite exact law references in the report:

Hiến pháp v4.6.3
Điều 7 Assembly First
Điều 28 Display / Nuxt render-shell boundary
Điều 30 Regression protection
Điều 31 Integrity / audit
Điều 32 Approval / governance
Điều 33 PostgreSQL / Directus / Nuxt boundary
Điều 35 DOT governance
Điều 37 Governance organization
Điều 38 / Điều 39 IU / Text-as-Code / Knowledge Graph
Điều 45 PG-native Queue & Task Orchestration Law
Điều 34 Workflow Law draft — decision path only, do not enact

2. Non-negotiable doctrine

Rev2 must make these hard invariants explicit:

IU is the reusable center / process brick.
Workflow = graph/list of IU-backed step bricks or IU bundles.
Task = operational envelope around IU-backed instruction/context/input/output contracts.
MOW orchestrates IU-backed workflow graph; it does not execute work.
MOT creates/manages task envelope; it is not executor.
MOIT renders input forms from approved field/form registry, bound to IU/task context.
MOUT renders read-only/reference/report outputs from PG/Directus/DOT, bound to IU/task context.
Event system carries signal/ref, not heavy IU body.
PG/DOT/registry remains SSOT.
External open-source tools are adapters/transports/executors/gateways only, never core owners.
Nuxt never connects directly to core queue/broker.
Governance UI shows problems, summaries and drill-down, not raw event noise.
User-facing workflow UI must use familiar traffic-light semantics to reduce training burden.
No implementation, migration, DB mutation, Qdrant/vector work, law enactment, or final tool selection.

3. Clarify current lifecycle stage

Add an explicit section:

Current Stage: Requirement Rev2, Not Final Design

State clearly:

We are completing official requirement / đầu bài.
Existing master design rev1 is only a baseline draft.
Design rev2 must be derived after requirement rev2 is reviewed.
Implementation Phase 0 remains blocked until requirement+design patch PASS and user approval.

4. Required sections in Requirement Rev2

4.1 User vision and operating model

Capture the user’s intended mental model in non-technical language:

Build the smallest strong unit first.
IU is a smart reusable information/process brick.
A process can be short or extremely long; the engine should not care.
A 500-step workflow is assembled from 500 IU-backed steps or 500 IU bundles.
Build once, reuse many times.
Edit/split/merge/rebundle once under governance; all future uses benefit according to version policy.
Standard architecture should be combined with IU-centered architecture, not replace it.

4.2 IU-Centered Doctrine

Define:

Information Unit as Process Brick
IU Bundle / Step Pack
IU-backed workflow step
IU-backed task envelope
IU event contract
IU version pinning
IU usage evidence
KG feedback loop

4.3 Workflow UI / Process UI requirement

This is a critical missing part.

Add a requirement for a workflow UI that shows not just the standard process definition, but also runtime status per work item / step.

Must include:

A. Two views

Standard Process View
- Shows the approved workflow template / process map.
- Built from IU-backed steps or IU bundles.
- Shows normal order / graph / branch / parallel path.
- Used for learning, inspection, governance and proposal mode.
Runtime Progress View
- Shows a specific workflow run.
- Each step/task has its own state, progress, assignee/executor, deadline, escalation and evidence.
- A long workflow should be readable without overwhelming the user.

B. Step/task state requirements

Each workflow step/task must visibly support at least these states:

not_started
ready
in_progress
waiting_dependency
waiting_human
blocked
overdue
failed
cannot_complete
completed
skipped / cancelled where applicable

C. Traffic-light semantics

Use socially familiar traffic-light signals to reduce training:

Green: completed / healthy / on track.
Yellow / amber: pending, waiting, needs attention soon, risk of delay.
Red: overdue, failed, blocked, cannot complete, DLQ / intervention needed.
Grey: not started / not applicable / skipped.
Blue or neutral: informational / in progress, if needed.

Must not rely on color alone: include icon/text label for accessibility.

D. Progress and exception visibility

UI must show:

overall workflow progress percentage.
counts: completed / in progress / pending / overdue / blocked / failed.
current active step(s).
next expected step(s).
deadline remaining / overdue duration.
owner/assignee/executor class.
last event / last update summary.
escalation status.
DLQ/retry state where relevant.
drill-down to task evidence and IU source.

Default view must show exceptions and summaries, not raw event noise.

E. Long workflow usability

For workflows with 100–500+ steps:

collapse by phase / subworkflow / department / professional domain.
show summary per segment.
allow drill-down only when needed.
support search by task, IU, assignee, status, trace_id, correlation_id.
show critical path / blocked chain.
support timeline and graph view where useful.

F. Proposal mode

Process UI must preserve MOW proposal mode:

normal mode: view approved process and runtime states.
proposal mode: propose add/edit/delete/reorder step or IU bundle.
proposals enter governance queue, not direct registry mutation.
backend permission filter; same UI pattern across roles.

4.4 MOW requirements

MOW must be defined as IU assembly orchestrator:

owns workflow registry / graph / lifecycle / proposal governance.
assembles IU-backed step bricks into process templates.
instantiates workflow runs.
tracks run state and each step state.
supports short, long, nested and parallel workflows.
supports time trigger, previous-output trigger, manual human trigger, composite AND/OR trigger.
does not own executor runtime or queue core.

4.5 MOT requirements

MOT must be defined as task envelope factory:

task has header, input, reference, instruction and runtime metadata.
instruction/context is IU-backed.
input is MOIT-backed.
reference/output is MOUT-backed.
supports human-in-the-loop and fully automated tasks.
tracks task state, deadline, escalation, retry, idempotency, trace/correlation.
does not execute work.

4.6 MOIT requirements

Approved field registry only.
No rogue form.
Field/form may link to IU explaining field meaning, policy, validation.
Direct-write vs staging/approval queue is config-driven.
Nuxt form component is render shell only.

4.7 MOUT requirements

Read-only reference/output/report blocks.
Live data from PG/Directus/DOT.
Permission filtered backend-side.
Realtime through governed gateway/projection.
Output table/report must declare source IU/context and SQL/DOT links.

4.8 Event 5-layer requirements

Reconcile Bắt sự kiện của PG(3).docx and include:

Event Producers — produce events only; no business execution logic.
Broker/Event Bus — separates pub/sub fanout from job queue.
Consumers/Workers/Executors — queue does not run scripts; workers consume and execute.
Realtime Gateway — Nuxt never reads core queue directly.
DLQ/Recovery/Governance — retry, replay, poison isolation, DLQ rescue.

Also require:

ACK/NACK.
timeout.
idempotency.
replay.
schema registry.
trace_id/correlation_id.
event payload carries refs, not heavy body.
worker fetches details by ref from PG/Directus/DOT.

4.9 Governance UI requirement

Governance UI is a dashboard / cockpit, not a log folder.

Must show:

problems first.
traffic-light status.
aggregate counts.
concise AI/worker status summaries.
drill-down on demand.
DLQ replay/rescue with approval.
silent worker / heartbeat issue.
event lag.
stuck task / overdue task.
proposal queue.
impact analysis before changing IU used by active workflows.

4.10 Old infrastructure coverage matrix

Add matrix covering:

IU foundation.
queue/event existing substrate.
DOT substrate.
cut pipeline.
Directus/Nuxt boundary.
vector boundary.
existing workflow/task tables.
governance/approval.

4.11 Constitution and Law Clause Matrix

Add clause-by-clause compliance matrix.

Columns:

law/principle.
binding requirement.
requirement rev2 satisfaction.
design implication.
remaining risk.
sentinel test.

4.12 PG Maximization Map

Show PG as SSOT for:

event_outbox.
event_type_registry and JSON schema.
trace/correlation.
idempotency.
retry policy.
job_dead_letter / DLQ.
replay ledger.
governance state.
workflow/task/field/form/output registries.
executor_class_registry.
DOT catalog.
healthcheck/audit.

4.13 OSS candidate strategy language

Do not make final tool choices.

Use decision classes:

confirmed_invariant.
reject_as_core_owner.
reject_as_primary_substrate_now.
defer_until_profile_trigger.
future_adapter_slot_preserved.
sandbox/reference_only.
not_a_second_SoT.

Reclassify:

pg-boss / Graphile Worker.
Temporal / Camunda / Airflow.
Benthos / Redpanda Connect.
NATS / Redis Streams.
Hasura / Directus realtime.
Watermill.
SSE / WebSocket / Centrifugo.
OpenTelemetry / Jaeger.

4.14 Open decisions register

Must list at least:

Điều 34 promote vs merge/archive.
Generic proposal table vs per-domain proposal tables.
executor_class_registry ownership: Điều XX vs Điều 45 cross-reference.
realtime gateway implementation path.
threshold for Benthos/NATS.
Temporal/Camunda re-evaluation trigger.
review_decision schema ownership.
event_type_registry schema JSON shape and compatibility mode.
workflow UI graph/timeline representation details.
status vocabulary final mapping to Điều 45 state machine.

5. Acceptance criteria

Requirement Rev2 PASS only if:

It clearly states current stage is requirement, not final design.
It elevates IU to reusable process brick, not mere documentation reference.
It proves 2-step and 500-step workflows share the same IU-backed assembly primitive.
It includes workflow UI status/progress/traffic-light requirements.
It includes step/task state vocabulary and exception visibility.
It reconciles event 5-layer from uploaded document.
It has old infrastructure coverage matrix.
It has constitution/law clause matrix.
It has PG maximization map.
It has agreed details completeness checklist.
It preserves Assembly First and no second SoT.
It does not trigger implementation.

6. Required outputs

Create/update requirement document Rev2:
- knowledge/dev/requirements/iu-mow-mot-event-foundation-requirements.md
- or if preserving rev1, create:
- knowledge/dev/requirements/iu-centered-4mothers-event-foundation-requirements-rev2.md
Create patch report:
- knowledge/dev/reports/architecture/iu-centered-4mothers-event-requirement-rev2-patch-report-2026-05-27.md
Do not patch master design yet unless explicitly creating a short design_implications appendix. Full design rev2 comes after requirement review.

7. Forbidden actions

No PG mutation.
No Directus mutation.
No Qdrant/vector write.
No migration.
No DOT command execution.
No law enactment.
No implementation macro.
No final OSS tool selection.
No UI deployment.

8. Final instruction to Agent

Prefer well-reasoned disagreement over passive acceptance. But any disagreement must still preserve the user’s central doctrine: IU is the center, and MOW/MOT/MOIT/MOUT are factories/orchestrators around IU.

The objective is not to produce a large-looking document. The objective is to produce an official requirement brief that the user can review and approve before design rev2 and implementation.

End prompt.