KB-1BDF

Branch E — MOW vs MOWD Decision Memo (RECOMMEND HYBRID) (2026-05-29)

5 min read Revision 1
mowdmowdecisionbranch-edieu37assembly-first2026-05-29

Branch E — MOW vs MOWD Decision Memo

Doc 05 (2026-05-29) — Recommendation: Option 3 (Hybrid)

Question (GPT-DIR): does workflow/process design require a new Mother of Workflow Design (MOWD), or should it be a subdomain of MOW (Mother of Workflows), or a hybrid?

Recommendation: HYBRID — MOW remains the Mother; workflow design becomes a governed def-side sub-registry / sub-factory under MOW. Do NOT create a fifth Mother now.

1. The three options

Option 1: Separate MOWD Option 2: MOW owns design+runtime as subdomains Option 3: Hybrid (recommended)
Shape 5th Mother factory row in governance_registry MOW absorbs design with no structural split MOW stays Mother; design is a governed sub-registry (distinct tables/laws/DOT) under MOW's ownership
New law / Đ37 registration Required (new factory + new governing law + Đ32 quorum + onboarding DOT) none none (binding records under MOW's existing factory row + future Điều XX app-layer)
Double-ownership risk High (MOWD vs MOW over workflow_def) Low Low (one owner = MOW; design vs run are subdomains, not separate agencies)
Over-fragmentation Yes (Đ7 / "avoid expanding 4 Mothers") No No

2. Evaluation against the required criteria

Criterion Verdict
Assembly First (Đ7 / NT8) Hybrid wins. "Default = reuse/extend"; Rev5 "introduces no new tables of its own." A 5th Mother is a parallel substrate, the opposite of assembly.
No double ownership (Đ37 §4.8/§4.12) "One domain max one primary law"; "one content owned by exactly one law." MOWD-as-Mother would contend with MOW over workflow_def. Hybrid keeps MOW the single owner.
PG-first (NT13) Equal — all options are PG rows. Hybrid reuses workflows/workflow_steps/workflow_change_requests + adds IU bindings.
IU-centered Hybrid wins: the design layer is IU-bound blueprints, naturally a subdomain of the same IU substrate, not a new factory.
Governance Hybrid: design changes flow through MOW's existing workflow_change_requests + Đ32; no new governance spine.
Scaling to 10k–100k workflows Equal at the data layer (PG + indexes). Treeview/filter (Doc 07) is owned by MOW's def-side regardless. A separate Mother adds no scaling benefit.
UI treeview / filter Hybrid: one workflow_categories hierarchy already exists; reuse it.
Trigger / report / source integration Hybrid: bindings (DOT/SQL/event/code/report) live on the design rows under MOW; MOT/MOUT/MOIT bind by reference, no ownership change.
Event/queue compatibility (Đ45) Hybrid: design emits register-before-emit events under MOW; Đ45 keeps queue/event ownership. A new Mother would still not own queue — so no gain.
Directus/Nuxt boundary (Đ28) Equal — render-only shell over PG; unaffected by Mother count.

3. Why the design already points to Hybrid

The Rev2 design already separates blueprint from runtime inside MOW:

  • workflow_def / workflow_step_def / workflow_step_relations = def-time (blueprint).
  • workflow_run / step_run = runtime.
  • MOW.can_create already lists workflow_def, workflow_step_def, workflow_step_relations, workflow_change_request (REV2-04 §4.7 / REV2-10 §5.1); must_not_own = IU body, executor runtime, event/queue core, approval law, template lifecycle.
  • Owner-law for these children = "future Điều XX (app layer)" — i.e. an app-layer law, not a new Mother.
  • GPT-DIR itself states the recommended initial hypothesis is "Hybrid until cross-law review proves MOWD must be separate."

So "MOWD" is best realised as MOW's design subdomain = the workflow_design* sub-registry (Doc 06), governed under MOW's factory row and a future app-layer Điều XX.

4. Decision & exit clause

  • Adopt Hybrid. Implement workflow design as a MOW-owned sub-registry; reuse workflow_* tables; add IU bindings; reuse workflow_change_requests for Kaizen; bind (not own) MOT/MOIT/MOUT/event/SQL.
  • Do NOT register a MOWD factory row in governance_registry now (Đ37 registration + Đ32 quorum would be premature and risk double ownership).
  • Exit clause — revisit MOWD-as-separate only if cross-law review shows the design-layer governance materially conflicts with runtime orchestration ownership — concretely: (a) a distinct human-org-role law makes "workflow designers" a different agency than "workflow operators" (the flagged D-1 human-org-role gap), or (b) blueprint approval quorums must differ from runtime-change quorums in a way that cannot live under one MOW factory row. Until then, Hybrid.

5. Naming guidance

Use "MOW Design Sub-Registry" (or "MOW.design") in artifacts, not "MOWD-the-Mother," to avoid implying a fifth factory. The term MOWD should denote the subdomain, governed by MOW, pending the app-layer Điều XX.

Back to Knowledge Hub knowledge/dev/reports/architecture/iu-design-live-gap-dot-ops-workflow-design-registry-audit-2026-05-29/05-mow-vs-mowd-decision-memo.md