Master Design Rev2 — Open Decisions + Implementation Readiness (WS8)

Path: knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/06-open-decisions-and-readiness.md Status: DRAFT Rev2 (document-only). Companion to 00-master-design-rev2.md. Date: 2026-05-27 Authority: Rev2 brief §19 (Open Decisions Register OD1..OD15), §12 (Old Infra incl. CRS rows requiring survey), §15 (OSS), §11 (No-double-ownership), §16 (Điều 34 decision path), §17 PARTIAL conditions (raw-source + candidate-registry survey). Boundary: This document resolves open decisions where Master Design Rev2 has authority, defers to Council where authority is theirs, and plans the sequencing for Phase 0/1 implementation without implementing. No PG mutation. No DOT command run. No law enactment. No final OSS pick.

§1. Reading guide

For each open decision (OD1..OD15) we record:

Default proposal from Rev2 brief.
Decision in this design — kept / refined / deferred.
Reason — the design constraint that drives the call.
Cross-refs — design landing site that implements the call.
Phase impact — at what phase the decision becomes load-bearing.

§S1..§S15 follow this template per OD. §S20 collects the readiness plan + sequencing.

§S1. OD1 — Điều 34 decision path

Default proposal (Rev2 §16): Council decides among 3 branches: (1) promote Điều 34 to workflow grammar law, (2) merge / archive into Điều XX framework law, (3) keep as DRAFT.

Decision in this design: Deferred to Council. This design does not treat Điều 34 as authority anywhere. The 9-state floor, transition matrix, workflow grammar, MOW orchestration are all anchored to Điều 45 v1.0 (state machine + queue/event) + future Điều XX framework law (4 Mothers application layer). Điều 34 is invoked only as a decision path, never as authority.

Reason: Rev2 §16 binding: "Rev2 không quyết. Rev2 không sửa luật, không enact, không draft law mới." Same applies to design — no design row claims Điều 34 as authority.

Cross-ref: 01-requirement-traceability-matrix.md §15 (Điều 34 row); each WS file's no-double-ownership statement.

Phase impact: Phase 0 begins independent of Điều 34 decision. If Council promotes → workflow grammar inherits; if Council merges → Điều XX absorbs vocabulary; if Council keeps DRAFT → design proceeds on Điều 45 + Điều XX as today.

Sentinel: Master Design Rev2 cites Điều 34 zero times as authority; only one decision-path enumeration appears (here).

MP-D10 — Điều 34 sequencing (explicit binding):

Master Design Rev2 does NOT depend on Điều 34. The 9-state floor, 4 Mothers binding, IU brick/bundle architecture, Event 5-layer, and OSS strategy are all anchored to Điều 45 v1.0 (substrate) + future Điều XX (4 Mothers application framework). Approval of Master Design Rev2 does not require, and must not be blocked by, the OD1 decision.
Phase 0 may proceed without OD1. Phase 0 closes IU-side gaps only: G1 (review_decision_id for split/merge — Điều 38/39 surface), G2 (fn_iu_post_cut_axis_materialize autowire — Điều 45 substrate), G7 candidate registry survey (read-only design). None of these touches workflow/application-law surface; they are safe to land while OD1 is open.
Phase 1 law/application-workflow extraction is gated. Any Phase 1 work that would draft, enact, modify, or codify workflow-grammar / application-workflow vocabulary at the law layer (i.e. content that would land in a law file, in Điều 34, or in a future Điều XX clause) MUST EITHER:
- (a) wait on OD1 (Council decision on Điều 34 promote / merge-into-Điều-XX / keep-draft); or
- (b) proceed under a clearly-named future Điều XX boundary, with an explicit statement that the work is anchored to Điều XX (not to Điều 34) and that any subsequent Council ruling on OD1 will reconcile naming/numbering without re-deriving substance.
Implementation (non-law) extensions are not gated by OD1. Phase 1 substrate work in 06-… §S20.2 (state_machine_registry, executor_class_registry, idempotency_registry, dlq_replay_request, schema_change_policy, proposal/review_decision, gateway, etc.) is substrate-layer work owned by Điều 45 + future Điều XX referent; it proceeds independently.

Sentinel: any Phase 1 macro that drafts law text MUST declare in its authority block which of (a) or (b) it uses; absence of that declaration is a forbidden-block violation.

Required survey for raw-source audit (Rev2 §17 PARTIAL): Council may demand direct audit of 4 mẹ mở rộng.txt + Bắt sự kiện của PG(3).docx. Design proceeds on GPT recheck consolidation source per Rev2 §17. If Council demands raw audit, run a separate document-only macro to upload raw files to KB; this design adapts only if raw audit contradicts Rev2 reconciliation (low-risk — every reconciled lesson is checklist-traceable per Rev2 §6.6).

§S2. OD2 — Generic proposal table vs per-domain

Default proposal (Rev2 §19 OD2): Reuse workflow_change_requests + generic proposal table for IU / MOT / MOIT / MOUT proposals.

Decision in this design: Refined. Keep workflow_change_requests [VL row 17] for workflow proposals only (graph changes — add/edit/delete step + relations + condition). Introduce a new generic proposal table for non-workflow proposals:

proposal
  proposal_id              uuid PK
  proposal_kind            text   -- 'iu_split' | 'iu_merge' | 'iu_bundle_create' | 'iu_bundle_edit' |
                                  --  'kg_edge_add' | 'kg_edge_remove' | 'mot_template_edit' |
                                  --  'moit_field_edit' | 'moit_form_edit' | 'mout_view_edit' |
                                  --  'state_machine_extension' | 'executor_class_add'
  proposer_class           text   -- 'human' | 'kg_feedback' | 'governance_audit'
  proposer_id              uuid nullable
  proposed_at              timestamptz
  proposal_state           text   -- 'draft' | 'submitted' | 'review' | 'approved' | 'rejected' | 'merged'
  affected_artifact_refs   jsonb  -- iu_unit_ids[], step_def_ids[], etc.
  proposed_action_jsonb    jsonb  -- DSL describing the change
  evidence_refs_jsonb      jsonb  -- iu_usage_evidence ids, audit refs
  approval_id              uuid nullable    -- Điều 32 approval ref
  outcome_jsonb            jsonb nullable
  created_at               timestamptz
  trace_id                 text

Reason: Workflow proposals already have workflow_change_requests which is shape-fit. Other proposal kinds (IU split / KG edge / MOT template / MOIT field / MOUT view / state extension) need a more flexible payload and don't fit workflow_change_requests columns. A second generic table avoids over-extending the workflow one.

Cross-ref: 02-step-state-machine-… §8 (proposal mode shape); 04-iu-centered-… §3.5 (KG bridge); §3.7 (bundle proposal); §6 (governance lifecycle).

Phase impact: Phase 1 builds proposal table; Phase 0 may use workflow_change_requests for any in-flight workflow proposals.

Sentinel: No KG / IU / bundle / MOT / MOIT / MOUT proposal lands in workflow_change_requests; workflow proposals never land in generic proposal.

§S3. OD3 — `executor_class_registry` ownership

Default proposal (Rev2 §19 OD3): Cross-ref — Điều XX referent, Điều 45 substrate.

Decision in this design: Default kept. Executor class registry owned by future Điều XX (4 Mothers framework law) as application-layer concept; substrate (rows + invocation lifecycle) cross-refs Điều 45 §11.5 executor boundary. Concretely:

The classification (DOT / SQL / AI / Human / External / Notification / Render) is application-layer governance (Điều XX referent).
The lifecycle (how invocation, ACK/NACK, retry, idempotency) is substrate (Điều 45 §11.5 + §15.5).
The table lives in PG; both laws reference the same registry without double-owning.

Reason: Application-layer concern (which executor kinds exist; their config) belongs to Điều XX; substrate lifecycle belongs to Điều 45. Splitting cleanly avoids double ownership.

Cross-ref: 03-event-5layer-… §5.1 (executor_class_registry schema); 04-iu-centered-… §4.2 (MOT calls executor class).

Phase impact: Phase 1 — schema in PG; Phase 0 — design only.

Sentinel: executor_class_registry row carries executor_kind (Điều XX referent) + mutating flag (Điều 35 v5.2) + heartbeat_caller_fn (Điều 45 §15.5). No ambiguous ownership.

§S4. OD4 — Realtime gateway implementation path

Default proposal (Rev2 §19 OD4): Start Nuxt-route SSE shell calling backend abstraction; preserve Centrifugo slot.

Decision in this design: Default kept. Implementation path:

Phase 1: Nuxt server route /sse/topic/:topicId is shell only; calls backend gateway service (Node) via internal HTTP. Backend gateway reads event_subscription with delivery_kind='realtime_topic' and pushes to Nuxt shell.
Phase 2+: If client load remains <1k concurrent, keep native. If >1k OR multi-region, evaluate Centrifugo adapter (05-oss-candidate-strategy-rev2.md §3.11).
Always: Nuxt has zero direct PG connection. Permission filter + relevance filter live in backend gateway (Điều 33 v2.1, Điều 37 v3.3).

Reason: Per 05-… Gate A + B verdict for SSE / WebSocket / Centrifugo. Native start respects PG-first; Centrifugo deferred until profile trigger.

Cross-ref: 03-event-5layer-… §7; 05-… §3.11.

Phase impact: Phase 1 builds backend gateway service + topic registry.

Sentinel: No Nuxt source contains LISTEN, event_outbox, pg.connect, NOTIFY.

§S5. OD5 — CDC threshold (Benthos / NATS adoption)

Default proposal (Rev2 §19 OD5): Benthos after PG outbox lag p95 > X; NATS after multi-host worker.

Decision in this design: Refined with explicit triggers.

Benthos / Redpanda Connect adoption trigger: External mirror need arises (analytical warehouse, partner streaming integration, future Kafka federation) AND PG-native outbox-to-sink lag p95 > 5 seconds (initial threshold; tune per data domain in Phase 3+).
NATS adoption trigger: Worker fleet runs on >1 host (multi-host) AND per-event fan-out >10 subscribers AND PG NOTIFY + polling lag p95 > 2 seconds.

Both adoptions are bounded: SoT stays PG (event_outbox + event_type_registry); the OSS tool acts as transport / mirror only. Adapter contract enforces SoT-pointback row.

Reason: Single-VPS PG-native substrate is sufficient for current scale per memory. Adoption triggers prevent premature complexity (Hiến pháp NT13 PG-first).

Cross-ref: 05-… §3.5 (Benthos), §3.6 (NATS), §3.7 (Redis Streams as alternative to NATS).

Phase impact: Phase 3+ for Benthos external mirror; Phase 4+ for NATS multi-host.

Sentinel: Adoption requires Council Round 1 (Điều 37) decision + adapter SoT-pointback proof.

§S6. OD6 — Temporal / Camunda re-evaluation trigger

Default proposal (Rev2 §19 OD6): Post-Phase 6 if MOW saturates or >100k active long-running.

Decision in this design: Default kept. Concretely:

Temporal re-evaluation trigger: Post-Phase 6 + (a) MOW orchestrator p95 step-advance latency >1s sustained, AND (b) >100k active long-running workflow_runs, AND (c) PG-native scheduling cannot meet p95 SLA with horizontal worker scaling alone. Re-evaluation = Council Round (Điều 37) considering Temporal as bounded execution engine with workflow definitions staying in PG registry (Temporal as adapter).
Camunda re-evaluation trigger: No trigger (approval = Điều 32; reject as engine permanently). Reference-only labels (L6) remain valid.

Reason: PG-native MOW with Điều 45 substrate covers current and projected scale; OSS workflow engines impose state-vocab + config-first conflicts (05-… §3.2 + §3.3).

Cross-ref: 05-… §3.2 (Temporal); §3.3 (Camunda).

Phase impact: No impact through Phase 6; re-evaluation Phase 7+.

Sentinel: Master Design Rev2 names neither Temporal nor Camunda as substrate or engine.

§S7. OD7 — `review_decision` schema for split/merge (G1 closure)

Default proposal (Rev2 §19 OD7): Phase 0 closes; Điều XX referent.

Decision in this design: Default kept. Phase 0 macro will close G1 by adding review_decision_id to IU split/merge ops. Schema sketch (paper-only):

review_decision
  review_decision_id       uuid PK
  review_kind              text   -- 'iu_split' | 'iu_merge' | 'iu_bundle' | 'workflow_change'
  proposal_id              uuid FK -> proposal
  approval_id              uuid FK -> Điều 32 approval
  reviewer_id              uuid
  verdict                  text   -- 'approved' | 'rejected' | 'needs_revision'
  decision_rationale       text
  decided_at               timestamptz
  evidence_refs_jsonb      jsonb
  trace_id                 text

Existing IU split/merge ops (Điều 38/39 surface) will reference review_decision_id in their command body; current PARTIAL state is exactly the missing FK column.

Reason: Rev2 §12 row 3 [KG/G1] requires this. Audit + reversibility (Điều 30, 31).

Cross-ref: 04-iu-centered-… §3.5 (KG bridge); 04-… §6 (governance lifecycle).

Phase impact: Phase 0 closes G1.

Sentinel: After Phase 0, every IU split/merge op carries review_decision_id; before Phase 0, design treats split/merge as gated.

§S8. OD8 — Event schema JSON SoT shape + compatibility mode

Default proposal (Rev2 §19 OD8): event_type_registry with semver + forward-by-default.

Decision in this design: Refined. event_type_registry schema additions (paper):

event_type_registry
  event_type              text PK
  schema_jsonb            jsonb         -- JSON schema (Draft 2020-12)
  schema_version          text          -- semver
  compat_mode             text          -- 'forward' (DEFAULT) | 'backward' | 'full' | 'breaking_with_policy'
  active                  bool
  deprecated_at           timestamptz nullable
  schema_change_policy_id uuid nullable FK -> schema_change_policy
  producer_class_allowed  text[]        -- restrict which producer classes may emit
  …

schema_change_policy
  schema_change_policy_id uuid PK
  event_type              text FK
  from_schema_version     text
  to_schema_version       text
  cutover_at              timestamptz
  dual_write_window       interval
  migration_plan_text     text
  approval_id             uuid FK -> Điều 32

Compatibility rules:

forward (DEFAULT) — producer may add new optional fields; consumer must tolerate.
backward — producer must keep removed/renamed fields populated until consumer migrated; used during phase-out.
full — both directions; used for stable contracts during dual-write migration.
breaking_with_policy — major version bump; producer refuses to emit until schema_change_policy row + Điều 32 approval present.

Reason: Rev2 §6.5 + §14 requirement; addresses event_type_registry historical absence of source column (memory KB quirk).

Cross-ref: 03-event-5layer-… §6.3 (schema compat mode).

Phase impact: Phase 1 adds compat_mode + schema_change_policy rows for existing event types.

Sentinel: Producer write refused if (event_type, schema_version) not registered OR breaking_with_policy without policy row.

§S9. OD9 — Step state machine registry placement (G6 closure)

Default proposal (Rev2 §19 OD9): PG state_machine_registry table; declared-by-config.

Decision in this design: Default kept. Schema in 02-step-state-machine-… §2.

state_machine_registry lives in PG. Tables: state_machine_def, state_def, transition_def, state_facet_def, rollup_policy_def. Validation function fn_state_transition_validate(...) is the only path Nuxt / worker / MOW can use to move state.

Reason: Rev2 §7.3.5 design implication: state machine + transition validation backend-side; Nuxt zero logic; declare-by-config.

Cross-ref: 02-step-state-machine-… §2-§5.

Phase impact: Phase 0 / Phase 1 (registry tables exist before MOW + MOT operate at runtime).

Sentinel: Every step_run / task_run / workflow_run transition uses fn_state_transition_validate; raw UPDATE of state_code forbidden by trigger.

§S10. OD10 — DLQ replay ledger schema (G4)

Default proposal (Rev2 §19 OD10): Approval-gated via Điều 32.

Decision in this design: Default kept. Schema in 03-event-5layer-… §6.2 (dlq_replay_request). Every replay row references job_dead_letter_id + approval_id (Điều 32) + new idempotency key (per-namespace).

Cross-ref: 03-event-5layer-… §6.2; 02-step-state-machine-… §7.4 (DLQ replay UI).

Phase impact: Phase 1.

Sentinel: dlq_replay_request with proposal_state != 'submitted' MUST have non-null approval_id.

§S11. OD11 — Idempotency registry schema (G5)

Default proposal (Rev2 §19 OD11): Per-executor namespace + key.

Decision in this design: Default kept. Schema in 03-event-5layer-… §5.4 (idempotency_registry with (idempotency_namespace, idempotency_key) PK).

Cross-ref: 03-event-5layer-… §5.4.

Phase impact: Phase 1.

Sentinel: Every executor invocation carries (namespace, key); re-invocation returns prior outcome.

§S12. OD12 — Step states above 9 (paused/retrying/escalated/cancelled)

Default proposal (Rev2 §19 OD12): Defer; Master Design may propose.

Decision in this design: Refined. Adopt paused + cancelled as derived states; defer retrying + escalated to facets:

paused — derived state on workflow_run (extends step too if needed). Semantic class wait. Yellow_dark. Distinct from blocked/waiting because it's an explicit governance pause, not an external dependency.
cancelled — derived state, terminal, red_dark. Distinct from cannot_complete (per-actor declaration) — cancelled is workflow-level decision.
retrying — defer as facet on failed (transient): UI surfaces "retrying (attempt n/N)" via retry policy registry.
escalated — defer as facet on waiting: waiting_facet='waiting_human' + escalation_chain_id evidence + governance UI surfaces escalations.

Reason: 02-step-state-machine-… §4.5 — design rationale. Adding only justified derived states; rejecting facet-shaped ones to avoid state explosion. MP-D5 binding: derived states are extension states above the 9-state floor — they do not replace any floor code; adapters/tools must support full 9-state floor as baseline (Gate A); each derived state_def carries is_derived=true + floor_equivalent.

Cross-ref: 02-step-state-machine-… §4.5; §3.1 (state list).

Phase impact: Phase 1 (state_def rows for paused + cancelled).

Sentinel: State machine has exactly 11 codes (9 floor + paused + cancelled). Any additional code requires a state_def.justification row + floor_equivalent.

§S13. OD13 — `dot_function_registry` ownership / naming

Default proposal (Rev2 §19 OD13): MOUT-aligned namespace.

Decision in this design: Default kept. Registry SoT in PG. Naming convention:

dot.fn.<scope>.<verb>_<noun>
  scope ∈ {mout | moit | mow | iu | event | governance}
  verb_noun examples:
    dot.fn.mout.compute_invoice_total
    dot.fn.mout.aggregate_workflow_runtime
    dot.fn.moit.validate_field_dependency
    dot.fn.iu.materialize_axis
    dot.fn.event.lag_compute

Registry row (paper):

dot_function_registry
  function_ref             text PK    -- 'dot.fn.mout.compute_invoice_total'
  scope                    text       -- 'mout' | 'moit' | 'mow' | 'iu' | 'event' | 'governance'
  pg_function_name         text       -- actual PG function name
  signature_jsonb          jsonb      -- arg types + return type
  mutating                 bool
  config_jsonb             jsonb
  iu_source_ref            text nullable    -- IU declaring this output context
  active                   bool

Reason: OD13 default + survey gate (§S1) confirms registry exists or design adapts. MOUT-aligned naming makes ownership unambiguous.

Cross-ref: 04-iu-centered-… §4.4.

Phase impact: Phase 1 survey + register existing functions. MP-D7 (06-… §S16) applies: registry reference gated by survey VL or shape-adapter.

Sentinel: Every DOT function called from MOUT routes through dot_function_registry.

§S14. OD14 — Governance UI category taxonomy

Default proposal (Rev2 §19 OD14): Rev2 §7.4 categories as v1.

Decision in this design: Default kept. v1 categories: DLQ messages / silent workers / overdue / schema violations / event lag / integrity warnings / failed cuts / orphan workflows.

Cross-ref: 02-step-state-machine-… §7.2 (governance views + source views).

Phase impact: Phase 1.

Sentinel: Governance default route returns exactly these category counts.

§S15. OD15 — IU version policy for active workflows

Default proposal (Rev2 §19 OD15): Pin by default + opt-in upgrade per workflow.

Decision in this design: Default kept. Per 04-iu-centered-… §5: per-workflow iu_pin_policy column with default pin. Per-step override available via hybrid_per_step. Migration of active run requires Điều 32 approval.

Cross-ref: 04-iu-centered-… §5.

Phase impact: Phase 1.

Sentinel: Zero step_run.pinned_iu_version_id UPDATE without approval_id reference in audit.

§S16. Candidate registry survey gate (G7 — Rev2 §17 PARTIAL condition)

This is not an OD row, but a hard gate inherited from Rev2 §17 PARTIAL conditions and §12 rows 28-31 evidence_level=candidate_requires_survey.

Survey scope (read-only PG survey in next macro):

Candidate registry	Rev2 §12 row	Confirm questions
`field_registry`	28	Table exists? Column shape? FK to IU? Live row count? Live operational?
`input_form_registry`	29	Same set
`output_table_registry`	30	Same set
`dot_function_registry`	31	Same set + naming convention currently followed?

Survey mode: Read-only via mcp__claude_ai_Incomex_VPS__query_pg (STABLE functions / SELECT only). Memory feedback-ssh-workflow-admin-write-channel-pattern: writes need SSH path; reads use MCP. Survey IS reads only.

Survey output: A separate document-only macro IU_4MOTHERS_CANDIDATE_REGISTRY_SURVEY_DOCUMENT_ONLY_*X produces a single survey report knowledge/dev/design/v0.6-iu-4mothers-event-foundation-rev2/08-candidate-registry-survey.md (paper-only). Survey decides:

If all 4 registries verified_live with expected shape → CRS rows in 01-… §11 advance to VL; 04-… §4.3 + §4.4 design becomes phase-1 actionable.
If any registry differs → design adapts (extension columns / new shape) before Phase 1.

Sentinel for this design: No Phase-1 implementation depends on CRS rows until survey returns VL.

MP-D7 — Candidate registry survey sentinel (binding, cross-document): No implementation, migration, DDL, or runtime call anywhere in the system may reference field_registry, input_form_registry, output_table_registry, or dot_function_registry by name until ONE of:

The Candidate Registry Survey macro (IU_4MOTHERS_CANDIDATE_REGISTRY_SURVEY_DOCUMENT_ONLY_*X) marks that specific registry verified_live with confirmed shape in 08-candidate-registry-survey.md; or
A bounded shape-adapter is registered in external_tool_registry (or equivalent paper registry) declaring (a) the registry's actual shape, (b) the adapter contract translating to the design-assumed shape, and (c) Điều 32 approval of the adapter.

Until one of those conditions holds, any code path or migration referring to these four names by literal must be refused at design review (sentinel grep across migrations + worker code + Nuxt routes + DOT functions). This sentinel applies to Phase 1 onward; Phase 0 may only reference these names in paper-only design documents (this WS), never in executable artifacts.

Cross-references for sentinel grep targets:

04-iu-centered-4mothers-binding-design.md §4.3 — MOIT design references field_registry / input_form_registry as paper-only, gated by this sentinel.
04-iu-centered-4mothers-binding-design.md §4.4 — MOUT design references output_table_registry / dot_function_registry as paper-only, gated by this sentinel.
00-master-design-rev2.md §10 PG Maximization Map — the four rows are explicitly labeled CRS (Candidate Requires Survey); gated.
00-master-design-rev2.md §13 cross-document sentinels — sentinel #8 (G7) inherits this stricter wording.

§S17. Raw-source audit decision (Rev2 §17 PARTIAL condition)

Condition: Council may demand direct audit of 4 mẹ mở rộng.txt + Bắt sự kiện của PG(3).docx raw files (Rev2 §17 PARTIAL + MP2-revised).

Decision in this design: Design accepts current state — GPT recheck report iu-4mothers-event-foundation-gpt-recheck-after-drive-upload-2026-05-27.md is the accessible consolidation source. If Council demands direct raw audit, a separate document-only macro uploads the 2 raw files into KB; this design re-verifies Rev2 §6.6 reconciliation against the raw text. Risk is low — every reconciled lesson is checklist-traceable.

Sentinel: If raw audit returns a missing lesson, file an MP-7 patch to Rev2 brief before Phase 1.

§S18. Extension registries summary

Registries proposed in this design (all paper-only; require Phase 0/1 governance + migration):

Registry / table	Purpose	Source design section	OD ref
`state_machine_registry` (`state_machine_def` + `state_def` + `transition_def` + `state_facet_def` + `rollup_policy_def`)	step/task/workflow_run state machine substrate	`02-…` §2	OD9
`executor_class_registry`	executor class catalog	`03-…` §5.1	OD3 / G3
`idempotency_registry`	per-executor idempotency keys	`03-…` §5.4	OD11 / G5
`retry_policy_registry`	retry policies	`03-…` §5.3	—
`dlq_replay_request`	DLQ replay ledger	`03-…` §6.2	OD10 / G4
`schema_change_policy`	event schema breaking-change policy	this doc §S8	OD8
`realtime_gateway_topic_registry`	gateway topics	`03-…` §7.3	OD4
`event_validation_audit`	producer validation reject log	`03-…` §6.6	—
`iu_usage_evidence`	8-signal usage evidence	`03-…` §9 / `04-…` §7	Rev2 §10 GAP
`iu_process_binding`	IU brick fields → step/task/form/output binding	`04-…` §3.1	—
`iu_assembly_slot_registry`	assembly slot taxonomy	`04-…` §3.1	—
`proposal` (generic)	non-workflow proposals	this doc §S2	OD2
`review_decision`	review decisions for proposals	this doc §S7	OD7 / G1
`ui_design_system_registry` (lives in `dot_config vocab.ui.*` or Directus content registry)	traffic-light tokens, icon tokens, a11y palette	`02-…` §3.2 / §3.5	MP4
`external_tool_registry`	birth registry for any future OSS tool adoption	`05-…` §5	—
`failure_class_registry`	classification taxonomy for `step.failed` events	`02-…` §4.2	—
`dot_function_registry` (extension if missing)	DOT functions for MOUT / MOIT	`04-…` §4.4	OD13 / G7
`workflow_run` + `step_run` + `task_run` (runtime envelope on top of existing `workflows`/`tasks`)	runtime instances with pinned IU version + state_code + waiting_facet + trace_id	`02-…` §2.2 / `04-…` §4	—
`workflow_run_snapshot`	resume-safe runtime materialization	`04-…` §4.1	—
`step_run_output_snapshot` + `step_run_correction_cycle` (MP-D2)	original-output snapshot + correction-cycle ledger for reopen_for_correction (T8r/T12r)	`02-…` §4.2 notes	MP-D2
`step_run_state_history` (MP-D3)	per-step state-visit history (derived from transition events) preserving overdue marks across `overdue → completed`	`02-…` §4.2 notes	MP-D3

All proposed schemas are paper-only in this macro. Any DDL requires Phase 0/1 approval per implementation sequencing §S20.

§S19. Gap closure plan

Gap	Closes at	Owner	Acceptance
G1 `review_decision_id` for split/merge	Phase 0	Điều 38/39 surface team	All IU split/merge ops carry `review_decision_id`
G2 `fn_iu_post_cut_axis_materialize` autowire into `fn_cut_complete`	Phase 0	Điều 45 / CUT pipeline	Autowired; existing memory references this pending
G3 `executor_class_registry` ownership boundary	Phase 1	Điều XX referent / Điều 45 substrate	Table exists with both ownership fields
G4 `dlq_replay_request` ledger schema	Phase 1	Điều 45 / Điều 32	Schema + Điều 32 approval ID FK
G5 `idempotency_registry` schema	Phase 1	Điều 45 substrate	Per-namespace keys
G6 Step state machine registry placement	Phase 1	Điều 45 §6.7 substrate	`state_machine_registry` tables exist
G7 Candidate registries survey	Survey macro before Phase 1	Design team	All 4 registries either VL or shape-adapted
Rev2 §10 usage-evidence schema	Phase 2	Application layer	`iu_usage_evidence` populated by 8-signal functions

§S20. Implementation sequencing (after Master Design Rev2 user approval)

Phase order (paper-only sequencing; no implementation in this macro):

§S20.1 Phase 0 — Foundation gaps + survey

Run survey macro for G7 candidate registries (§S16).
Close G1 review_decision_id schema + bind IU split/merge ops.
Close G2 fn_iu_post_cut_axis_materialize autowire into fn_cut_complete (per memory roadmap).
Confirm Điều 34 decision path with Council (OD1) — design proceeds regardless (see §S1 MP-D10).

§S20.2 Phase 1 — Substrate extensions (DDL + config)

state_machine_registry tables + fn_state_transition_validate (G6 / OD9).
executor_class_registry (G3 / OD3) with existing DOT / SQL / human / notification executor classes registered.
retry_policy_registry + default policy rows.
idempotency_registry (G5 / OD11).
dlq_replay_request (G4 / OD10).
schema_change_policy (OD8) + event_type_registry.compat_mode populated for existing event types.
proposal generic table (OD2) + review_decision table.
ui_design_system_registry tokens (MP4 a11y) populated.
realtime_gateway_topic_registry (OD4) + backend gateway service skeleton.

§S20.3 Phase 2 — Application layer (4 Mothers binding)

iu_process_binding + iu_assembly_slot_registry (04-… §3.1).
workflow_step_def extension columns + workflow_run / step_run / task_run runtime tables (02-… §2.2 + 04-… §4).
workflow_run_snapshot materialization (04-… §4.1).
iu_usage_evidence (Rev2 §10) + 8-signal derivation functions.
KG feedback proposer (writes to generic proposal).
Governance UI (02-… §7) backend views.

§S20.4 Phase 3 — Realtime + observability

W3C trace_id propagation across all producers / workers (03-… §5.6).
Event lag monitor + governance UI lag pane (03-… §6.4).
Heartbeat caller pattern enforced on every worker class (03-… §5.5).
Backend realtime gateway service production-ready.

§S20.5 Phase 4 — External adapters (if profile triggers)

(Triggered) Benthos / Redpanda Connect bounded adapter for external mirror (per §S5).
(Triggered) NATS / Redis Streams as multi-host transport (per §S5).
(Triggered) OTel collector + Jaeger trace UI (per 05-… §3.13).

§S20.6 Phase 5 — Long-workflow UI hardening

Standard Process View + Runtime Progress View at long-workflow scale (02-… §6.3).
Critical path + blocked chain + lazy-load + mini-map.

§S20.7 Phase 6 — Council re-evaluations

Temporal re-evaluation if triggers met (per 05-… §3.2 + this doc §S6).
Centrifugo realtime if triggers met.

§S20.8 Phase 7+ — Continuous governance

Schema migrations via schema_change_policy + Điều 32 approval.
New executor class adoption via Điều 0-G birth.
KG feedback proposals integrated into governance review cadence.

Reversibility (Điều 30): Every phase produces rollback path. New table DDL has explicit DROP path. New function bodies are CREATE OR REPLACE-safe with prior body archived.

§S21. Cross-references and acceptance

Cross-refs:

All 15 ODs map back to default proposals in Rev2 §19.
Schema extensions documented in this design map to PG Maximization Map (Rev2 §14).
No-double-ownership respected per §S3 (OD3) and 04-iu-centered-… §4.6.

Acceptance:

A1. Every OD (OD1..OD15) has a decision row (kept / refined / deferred) with reason + cross-ref + phase impact + sentinel. A2. Candidate registry survey gate §S16 + raw-source audit decision §S17 captured. MP-D7 strict form present in §S16. A3. Extension registries summary §S18 captures all new tables/functions proposed across WS1..WS7 with paper-only status (now includes step_run_output_snapshot, step_run_correction_cycle, step_run_state_history per MP-D2/MP-D3). A4. Gap closure plan §S19 covers G1..G7 + Rev2 §10 evidence schema. A5. Implementation sequencing §S20 covers Phase 0..Phase 7+; no implementation triggered in this macro. MP-D10 sequencing present in §S1 (Phase 0 may proceed without OD1; Phase 1 law extraction gated). A6. Reversibility (Điều 30) is part of every phase.

End WS8 design.

Master Design Rev2 — Open Decisions + Implementation Readiness (WS8)

§1. Reading guide

§S1. OD1 — Điều 34 decision path

§S2. OD2 — Generic proposal table vs per-domain

§S3. OD3 — executor_class_registry ownership

§S4. OD4 — Realtime gateway implementation path

§S5. OD5 — CDC threshold (Benthos / NATS adoption)

§S6. OD6 — Temporal / Camunda re-evaluation trigger

§S7. OD7 — review_decision schema for split/merge (G1 closure)

§S8. OD8 — Event schema JSON SoT shape + compatibility mode

§S9. OD9 — Step state machine registry placement (G6 closure)

§S10. OD10 — DLQ replay ledger schema (G4)

§S11. OD11 — Idempotency registry schema (G5)

§S12. OD12 — Step states above 9 (paused/retrying/escalated/cancelled)

§S13. OD13 — dot_function_registry ownership / naming

§S14. OD14 — Governance UI category taxonomy

§S15. OD15 — IU version policy for active workflows

§S16. Candidate registry survey gate (G7 — Rev2 §17 PARTIAL condition)

§S17. Raw-source audit decision (Rev2 §17 PARTIAL condition)

§S18. Extension registries summary

§S19. Gap closure plan

§S20. Implementation sequencing (after Master Design Rev2 user approval)

§S20.1 Phase 0 — Foundation gaps + survey

§S20.2 Phase 1 — Substrate extensions (DDL + config)

§S20.3 Phase 2 — Application layer (4 Mothers binding)

§S20.4 Phase 3 — Realtime + observability

§S20.5 Phase 4 — External adapters (if profile triggers)

§S20.6 Phase 5 — Long-workflow UI hardening

§S20.7 Phase 6 — Council re-evaluations

§S20.8 Phase 7+ — Continuous governance

§S21. Cross-references and acceptance

§S3. OD3 — `executor_class_registry` ownership

§S7. OD7 — `review_decision` schema for split/merge (G1 closure)

§S13. OD13 — `dot_function_registry` ownership / naming