Incomex AI Portal
KB-5081

IU-Centered 4 Mothers + Event Foundation — Patch Instruction (2026-05-27)

10 min read Revision 1
requirementsdesign-patchiu-centered4-mothersevent-foundationworkflowtaskknowledge-graph2026-05-27

IU-Centered 4 Mothers + Event Foundation — Patch Instruction

Date: 2026-05-27 Author: GPT Council via Web Connector fallback Status: OFFICIAL PATCH INSTRUCTION — document-only, no production mutation Applies to: IU_4MOTHERS_EVENT_FOUNDATION_REQUIREMENT_DESIGN_PATCH_2000X

0. User directive captured

User has clarified that the deepest architecture principle is:

Miếng thông tin / Information Unit must be the center. Build the unit once; reuse many times. Even workflow steps should be assembled from IU or IU bundles. A 500-step process should be modelled as 500 IU-linked step bricks or 500 IU bundles, not as a bespoke workflow artifact detached from IU.

This must be elevated from an analogy to a binding requirement for the next requirement/design patch.

1. Verdict

The concept is architecturally sound and compatible with:

  • Điều 38 Information Unit First / Text-as-Code direction.
  • Điều 39 Knowledge Graph direction.
  • IU Fabric addendum: SQL remains SSOT; Directus is assembly/UI layer; vector/NoSQL is projection only; PG First; Assembly First.
  • Event 5-layer standard: producers, broker/event bus, consumers/workers, realtime gateway, DLQ/recovery/governance.
  • Assembly First: external tools are adapters, not owners.

But the current rev1 4 Mothers design is still too application-layer-centric. It says workflows/tasks reference IU, but does not yet make IU the reusable construction unit for workflow steps, task templates, form context, output context, event hooks, governance and KG feedback.

Therefore the rev2 patch must introduce an explicit IU-centered workflow/task assembly model.

2. Required architectural correction

2.1 From "workflow step references IU" to "workflow step is assembled from IU/IU bundle"

Rev1 language is insufficient if it only says:

  • workflow_step_def has iu_unit_id.
  • task_def has instruction_iu_unit_id.

Patch to:

  • Each workflow step definition must bind to one of:
    • a single IU;
    • an IU bundle / collection;
    • a typed IU assembly view;
    • a task template that itself is IU-backed.
  • The workflow graph is an ordered/conditional/parallel assembly of IU-backed step bricks.
  • A 500-step workflow must be expressible as 500 IU-backed steps or 500 IU bundles without new bespoke schema per step.
  • Step-specific logic must live in config/registry attached to the IU-backed step, not in Nuxt or ad-hoc worker code.

2.2 Define IU as the reusable process brick

Add section: Information Unit as Process Brick.

Required fields / relations:

  • iu_unit_id — stable knowledge brick.
  • iu_version_id — version pin for workflow stability.
  • iu_role_in_process — instruction | decision_gate | input_contract | output_contract | policy | checklist | SOP | validation_rule | event_hook | report_context.
  • assembly_slot — where this IU sits in MOW/MOT/MOIT/MOUT.
  • precondition_config — trigger/guard rules by config.
  • postcondition_config — emitted events, output contracts, next-step signal.
  • io_contract_refs — links to MOIT/MOUT schemas.
  • executor_class_ref — if the IU-backed step invokes DOT/SQL/AI/human/external/notification/render executor.
  • event_contract_ref — event type(s) produced/consumed.
  • kg_edge_refs — semantic dependencies / related IU / required context pack.
  • governance_state — proposed / approved / active / deprecated / archived.

2.3 Add IU Bundle / Step Pack concept

Some steps may need multiple units. Do not force merge.

Define:

  • iu_step_bundle or equivalent logical concept.
  • Bundle contains N IU members with ordered slots and typed roles.
  • Bundle can represent one workflow step, one task instruction pack, one form context, one output/report context.
  • Bundle is versioned and governed.
  • Bundle is assembled via PG registry, not hardcoded.

This avoids over-merging and aligns with KG feedback: typed edge/context-pack can be better than merge.

2.4 MOW must become an IU assembly orchestrator

Patch MOW:

  • MOW owns graph assembly over IU-backed step definitions.
  • MOW does not duplicate IU content.
  • MOW chooses next step by event/trigger/condition, but the step payload is an IU/IU-bundle reference plus config.
  • MOW supports long/short workflows uniformly: 2 steps or 500 steps are the same graph operation.
  • MOW proposal mode changes graph/bundle bindings, not raw text copies.

2.5 MOT must become an IU-backed task envelope

Patch MOT:

  • Task is an operational envelope around IU-backed instruction/context/io contracts.
  • Task body should not duplicate instruction text. It renders instruction IU or bundle.
  • Human task UI 4 regions are assembled from IU/MOIT/MOUT references:
    • Header = task runtime metadata.
    • Input = MOIT contract referenced by task/IU config.
    • Reference = MOUT contract referenced by task/IU config.
    • Instruction = IU or IU bundle.
  • Automated task uses same IU-backed contract but no human UI.
  • MOT remains not executor.

2.6 MOIT and MOUT must be IU-context-aware

Patch MOIT:

  • Input forms are not isolated forms; they are bound to IU-backed task/step context.
  • Field registry entries may link to IU explaining field meaning/policy/validation.
  • Direct write vs staging/approval is a config policy attached to the form/field/task context.

Patch MOUT:

  • Output/reference/report blocks are IU-backed views of PG/Directus state.
  • Reports should declare their source IU/context and SQL/DOT function links.
  • Realtime MOUT updates must flow through governed event/gateway path.

2.7 Event system must connect to IU directly

Add IU Event Contract:

  • IU can produce events when born, edited, split, merged, deprecated, linked, rendered, validated, or used in a workflow/task.
  • Workflow/task events must carry references, not heavy body:
    • iu_unit_id
    • iu_version_id
    • workflow_run_id
    • task_run_id
    • event_type
    • trace_id
    • correlation_id
  • Event payload must not copy large IU body.
  • Event type must register before emit.
  • Schema JSON lives in PG event_type_registry.
  • Worker fetches details from PG/Directus/DOT by ref.

2.8 Knowledge Graph feedback loop is mandatory

Rev2 must explicitly say Điều 39/KG is not only for search.

KG must help:

  • propose workflow step order.
  • detect missing dependency between steps.
  • suggest typed edges instead of merging units.
  • detect over-coupled step units.
  • detect orphan workflow steps.
  • impact analysis before changing an IU used by active workflows.
  • suggest split/merge/rebundle after usage evidence.

2.9 Usage evidence must drive improvement

Add usage evidence registry / concept:

  • co-used-in-workflow
  • co-triggered
  • co-edited
  • co-retrieved
  • failure correlation
  • repeated escalation
  • repeated human correction
  • event lag / DLQ correlation

These evidence signals feed governance decisions:

  • add edge.
  • create bundle.
  • split IU.
  • merge IU.
  • reparent IU.
  • change task template.
  • change workflow graph.
  • no action.

2.10 No over-engineering in IU core

Patch must preserve boundary:

  • Do not put all application logic into IU core.
  • IU stores stable knowledge, typed relations, contracts, references, and governance metadata.
  • Runtime execution remains with MOW/MOT/executors/queue/event core.
  • IU is the reusable brick, not the executor.

3. Required additions to patched documents

Requirement brief rev2

Add:

  1. IU-Centered Doctrine.
  2. Information Unit as Process Brick.
  3. Workflow = graph of IU-backed step bricks.
  4. Task = operational envelope over IU-backed contracts.
  5. IU Bundle / Step Pack requirement.
  6. IU Event Contract requirement.
  7. KG feedback loop requirement.
  8. Usage evidence requirement.
  9. No duplicate text / no copied instruction body invariant.
  10. Acceptance criteria for 500-step workflow assembly.

Master design rev2

Add:

  1. IU-centered layer diagram.
  2. IU-to-MOW/MOT/MOIT/MOUT binding model.
  3. Tables/concepts for workflow_step_def binding to IU/IU bundle.
  4. Task envelope diagram.
  5. IU event contract.
  6. KG/usage feedback loop.
  7. Revision impact model: what happens when an IU used by active workflow changes.
  8. Long workflow model: 2-step and 500-step workflows share same assembly primitive.

OSS critique rev2

Update:

  • Any external workflow/orchestration tool must consume IU-backed execution plan; it must not own workflow definition.
  • Any event/broker tool must transport IU refs and event refs; it must not own IU body or event taxonomy.
  • Any realtime tool must emit IU-aware summaries, not raw core queue rows.

Patch report

Must state:

  • Rev1 gap: IU was referenced but not yet elevated to workflow/task assembly substrate.
  • Rev2 correction: IU becomes the center; MOW/MOT/MOIT/MOUT assemble around it.

4. Acceptance criteria

Patch PASS only if:

  • A 500-step workflow can be explained as 500 IU-backed step definitions or IU bundles.
  • Editing an instruction once in IU can propagate to all future tasks/workflows according to version policy.
  • Active workflows can pin old IU versions while new workflows use newer versions.
  • A task can render instruction/context/input/output from IU/MOIT/MOUT without duplicated text body.
  • Event payloads carry IU refs, not heavy body.
  • KG feedback can propose edge/bundle/split/merge/no-action.
  • Design preserves PG-first, DOT, Directus/Nuxt boundary, queue/event law, and no-vector pollution.

5. Forbidden

  • No PG mutation.
  • No Directus mutation.
  • No Qdrant/vector work.
  • No law enactment.
  • No implementation macro.
  • No final OSS tool selection.
  • No migration.
  • No UI deployment.

IU_CENTERED_4MOTHERS_EVENT_REQUIREMENT_DESIGN_PATCH_2000X

This may replace or be merged into:

IU_4MOTHERS_EVENT_FOUNDATION_REQUIREMENT_DESIGN_PATCH_2000X

End instruction.

Back to Knowledge Hub knowledge/dev/requirements/iu-centered-4mothers-event-design-patch-instruction-2026-05-27.md