GPT Review — Master Design Rev2 Revision 4 + IU-Centered Roadmap

Date: 2026-05-28 Reviewer: GPT Council via Web Connector fallback

Documents read directly

KB:

• knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/09-governance-operability-observability-addendum.md revision 1
• knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/04-iu-centered-4mothers-binding-design.md revision 6
• knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/03-event-5layer-realtime-dlq-design.md revision 5
• knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/00-master-design-rev2.md revision 4 via search/truncated direct read
• knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/07-master-design-rev2-report.md revision 4 via search/truncated direct read

Uploaded source considered:

• Bắt sự kiện của PG(4).docx uploaded in current chat; relevant parts include 5 event layers, ACK/NACK, idempotency, schema registry, distributed tracing, governance UI, and tool options.

Verdict

MASTER_DESIGN_REV4_ACCEPT_AS_DESIGN_BASELINE_WITH_IU_SUBSTRATE_READINESS_GATE

Revision 4 is good enough to be accepted as the document-only Master Design baseline for the 4 Mothers + Event 5-layer architecture.

However, implementation should not proceed directly into MOW/MOT/MOIT/MOUT coding. The next phase must return to the Information Unit substrate and run readiness/survey/design-hardening macros to ensure IU can serve as the central process brick under the new vision.

Why Rev4 is now acceptable

1. IU remains the central assembly primitive: 2-step and 500-step workflows use the same IU-backed step / IU bundle primitive.
2. IU body singleton and no duplicate text invariant are explicit.
3. Render layer is permission-aware, audited, cache-keyed by permission scope, and prevents notification leaks.
4. IU version pinning and active workflow protection are explicit.
5. IU bundle / Step Pack maps to existing iu_piece_collection* substrate.
6. IU process brick now has 11 fields covering process role, assembly slot, pre/post condition configs, IO contract refs, executor class ref, event contract ref, KG edges, and governance state.
7. 4 Mothers are clearly binding shapes around IU, not owners of IU/event/approval.
8. Event 5-layer is documented and compatible with the uploaded PG event doctrine.
9. Input/staging/canonicalization path is explicit and safe.
10. Governance/observability/Kaizen anti-noise have been hardened in Rev4.
11. OSS tools are reconciled as adapter slots only; no final pick.
12. Điều 5 five-tier architecture is mapped to T6→T1 operating hierarchy and readiness gates.

Remaining non-blocking but mandatory next gates

Gate A — IU Substrate Readiness Review

Before further implementation, run a document-only IU readiness review to ask:

• Does the current IU substrate fully support the 11-field IU process brick?
• Are iu_process_binding, iu_assembly_slot_registry, iu_process_role vocab, event_contract_ref, executor_class_ref, io_contract_refs, and kg_edge_refs real, shape-adapted, or still paper?
• Can IU events be registered and emitted without body duplication?
• Can IU render be permission-filtered and audited?
• Can IU usage evidence receive signals from Kaizen/task/workflow/event outcomes?
• Is the existing no-vector staging/cut/composer pipeline compatible with this wider IU role?
• What must be upgraded before IU can be promoted for production use?

Gate B — Candidate Registry Survey

Survey:

• field_registry
• input_form_registry
• output_table_registry
• dot_function_registry

This remains required because MOIT/MOUT and MOT/JFT mass generation depend on it.

Gate C — Event/Queue Substrate Survey + Hardening Plan

Because IU is now a process brick and event citizen, survey/harden:

• event_outbox
• event_type_registry
• event_subscription
• job_queue
• job_dead_letter
• queue_heartbeat
• idempotency_registry
• retry_policy_registry
• dlq_replay_request
• executor_class_registry
• state_machine_registry

Determine what is live vs paper and what must be implemented to complete IU testing.

Gate D — Tier Registry Survey

Survey T6/T5/T4/T3 sources and classify each as existing, adaptable, or missing.

Gate E — Governance Ops Survey

Survey existing governance/agent/task/heartbeat/log/dashboard surfaces before building Governance Cockpit.

Roadmap recommendation

Recommended order:

1. Approve Master Design Rev4 as document-only baseline.
2. Run IU_CORE_PROCESS_BRICK_READINESS_AND_GAP_SURVEY_DOCUMENT_ONLY_*X.
3. Run IU_4MOTHERS_CANDIDATE_REGISTRY_SURVEY_DOCUMENT_ONLY_*X.
4. Run IU_EVENT_QUEUE_SUBSTRATE_READINESS_FOR_IU_PRODUCTION_DOCUMENT_ONLY_*X.
5. Run IU_4MOTHERS_TIER_REGISTRY_SURVEY_DOCUMENT_ONLY_*X.
6. Run IU_4MOTHERS_GOVERNANCE_OPS_SURVEY_DOCUMENT_ONLY_*X.
7. Only then decide whether to implement IU substrate upgrades first, Phase 0 IU gaps, or 4 Mothers substrate extensions.

Key warning

Do not implement MOW/MOT/MOIT/MOUT first if the IU process-brick substrate is incomplete. The whole architecture depends on IU being strong enough to carry process role, version pinning, event contracts, IO contracts, usage evidence, KG proposals, queue refs, governance state, and render/audit permissions.

If IU is too narrow, workflows will later require parallel body fields, duplicate task instructions, ad-hoc event payloads, or Nuxt logic — all of which violate the design.

Final recommendation

Approve Rev4 design baseline, but open the next workstream as IU substrate readiness rather than implementation.

Suggested next macro:

IU_CORE_PROCESS_BRICK_READINESS_AND_GAP_SURVEY_DOCUMENT_ONLY_3000X

No PG mutation, no Directus mutation, no Qdrant/vector write, no migration, no DOT command run, no implementation, no law enactment.