GPT Review — MOW Design Registry v3 P1–P3 Decision

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

P1 Naming decision

Recommended canonical name: MOW Design Registry.

Allowed alias: MOWD only as shorthand in discussion, with a mandatory definition: “MOWD = MOW Design Registry / design subdomain under MOW, not a fifth Mother.”

Avoid using “Mother of Workflow Design” in formal design titles because it suggests independent factory ownership and can conflict with Đ7 no-double-ownership and Đ37 factory governance.

P2 Reuse-first checklist

Before any schema proposal, Claude Code must map every logical registry to existing live PG artifacts. No new table is allowed until classified as REUSE / EXTEND / NEW / DEFER.

High-probability reuse/extend areas:

• DOT: dot_iu_command_catalog, dot_tools, DOT-related catalog rows.
• Events/triggers: event_type_registry, event/route/DLQ tables.
• Governance: governance_registry, review/approval/change request tables.
• IU/KG: information_unit, iu_relation, v_kg_edges_all, iu_sql_link.
• Workflow/task substrate: likely exists but must be inspected; current audit found inline/non-IU-bound gaps.
• Factory rows: MOW/MOT/MOIT/MOUT draft rows exist in governance_registry.

Likely NEW or EXTEND after inspection:

• workflow design blueprint registry if current workflow substrate cannot be safely extended.
• workflow step design binding if existing steps are inline/non-IU-bound.
• trigger design registry if existing event/trigger data lacks design-level condition/policy semantics.
• runtime binding view/table linking design versions to instances.

P3 Rollback policy

Default policy: new instances use latest active version; running instances continue on their pinned design version.

Rollback does not rewrite running instances by default. A rollback creates a new active version or reactivates a prior version for future starts. Running instances migrate only by explicit migration plan approved through governance.

Mandatory freeze mode: yes. Freeze new instance creation during rollback decision and activation to prevent more instances starting on the bad version.

Migration policy:

• require step mapping table old_step -> new_step;
• require state mapping and data compatibility check;
• require fallback for unmapped steps;
• require approval;
• dry-run before commit;
• if no safe mapping, continue old version or force-close with explicit authority.

Force close policy:

• only for unsafe/compliance/financially dangerous workflows;
• requires human/council approval;
• must notify owners and preserve audit trail;
• use terminal states such as cancelled/superseded/force_closed, never delete.

Handoff condition

Do not hand off to Claude Code CLI for detailed design until:

1. Naming is normalized to “MOW Design Registry”, with MOWD only as alias.
2. Live PG reuse-first survey is completed.
3. Logical registries are mapped to REUSE/EXTEND/NEW/DEFER.
4. Rollback/version pinning policy is written into v3.
5. Freeze mode and migration-plan requirement are added.
6. IU-centered invariant is preserved: no long inline workflow text when IU ref can be used.
7. Directus/Nuxt/Lark/vector boundaries are restated.