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) — Revision 5 (MP-D23..MP-D30 cross-law readiness items + Cross-Law Binding Readiness survey + IU-substrate gate added 2026-05-28; see §S18 reuse note, §S20.1 step 1d, §S24, and 10-…. Revision 4 added MP-D16..MP-D22 readiness items + Governance Ops Survey + updated survey sequencing §S18/§S20.1/§S23. Revision 3 added MP-D11..MP-D15 readiness §S22). Companion to 00-master-design-rev2.md. Date: 2026-05-27 (rev2) · 2026-05-28 (rev3 MP-D11..MP-D15) · 2026-05-28 (rev4 MP-D16..MP-D22) · 2026-05-28 (rev5 MP-D23..MP-D30) 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
`input_submission` (MP-D11)	staging row for Nuxt → backend gateway write path (raw text + audio_ref + attachments_ref + captured_context_jsonb); mediation only, NOT SoT	`08-…` §3.2	MP-D11
`input_routing_policy` (MP-D11)	per-`input_kind` direct vs workflow branch + permitted target kinds + size caps + canonicalizer executor	`08-…` §3.3	MP-D11
`audio_file_registry` + `attachment_registry` (MP-D11/MP-D13)	file blobs referenced by `audio_ref` / `attachments_ref`; never travel in event payloads	`08-…` §3.2 + §3.4	MP-D11 / MP-D13
`tier_registry` + (T6..T3 sources: domain / company / department / specialty — survey existing first) (MP-D12)	tier vocabulary above T2 for unified MOW canvas T6→T1	`08-…` §4.1 + §4.3	MP-D12
`task_template` (MP-D14)	matrix anchor row binding (IU/bundle, MOIT, MOUT, trigger, assignee, deadline, executor class, state machine, dashboard target, permission scope, escalation) for safe mass MOT/JFT generation	`08-…` §6.2 + `04-…` §4.2a	MP-D14
`assignee_policy` (MP-D14)	enumerable policy registry: `pic_from_role.<role>` / `pic_from_workflow_run.previous_actor` / `pic_from_agent_pool.<pool>` / `round_robin.<queue>` etc.	`08-…` §6.2 + §6.4	MP-D14
`deadline_policy` (MP-D14)	enumerable policy registry: `fixed_24h` / `business_calendar.+2d` / `sla_class.<class>` etc.	`08-…` §6.2 + §6.4	MP-D14
`escalation_policy` (MP-D14)	enumerable policy registry: `overdue_4h_pic_manager` / `cannot_complete_escalate_to_workflow_owner` etc.	`08-…` §6.2 + §6.4	MP-D14
`worker.transcription` + `worker.attachment_index` executor classes (MP-D11/MP-D13)	async transcription + attachment indexing; emit `input.audio_transcribed` / `input.attachment_indexed`	`03-…` §3.4a + `08-…` §3.4	MP-D11 / MP-D13
`vw_governance_kaizen_*` + `vw_governance_cannot_complete_cluster` + `vw_governance_failure_cluster` + `vw_governance_overdue_cluster` (MP-D15)	governance cockpit panels (Kaizen volume + quality, cannot_complete cluster, failure cluster, overdue cluster)	`08-…` §7.3 + §7.5	MP-D15
`agent_run` (MP-D15)	AI/agent run state for AI/Agent Ops Console (cross-links `executor_class_registry` + `dot_iu_command_run`)	`08-…` §7.4	MP-D15
`external_tool_registry` adapter slots (MP-D15)	candidate slots for observability (Prometheus / OTel / Jaeger / Tempo / Loki / Grafana) + AI ops (Langfuse / Helicone / Phoenix Arize); SoT-pointback required; no final pick in this macro	`08-…` §7.6 + `05-…` §5	MP-D15
`governance_problem` + `governance_problem_event_link` + `governance_problem_assignment` (MP-D17)	typed operations problem queue (16 classes, 5 severities, 12+3 lifecycle states) above existing detection sources; problems spawn changes, never are changes; auto-resolve needs source `*.resolved` event	`09-…` §4.7 + `02-…` §7.10	MP-D17
`governance_suppression_policy` + `governance_slo_policy` (MP-D17)	config-first suppression predicates + SLO/SLA objectives for the problem queue	`09-…` §4.5 + §4.7	MP-D17
`kaizen_lifecycle_state` (column on `input_submission`) + `fn_kaizen_duplicate_cluster` (MP-D18)	Kaizen review lifecycle + duplicate clustering (8 dimensions) + anti-noise; all backend, user flow unchanged	`09-…` §5	MP-D18
`input_submission.security_classification` + `worker.canonicalizer` direct-gate + retention config (`dot_config retention.staging.*`) (MP-D19)	direct-canonicalization allow/deny gate + PII/security classification + data lineage (staging↔canonical)	`09-…` §6 + `04-…` §4.3b	MP-D19

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

Rev5 cross-law binding artifacts (MP-D23..D26 — REUSE-ONLY, no new tables). The rev5 cross-law patch (10-…) introduces no new runtime table of its own. Every binding it adds is a row in an existing law registry (NT1/NT8 assembly-first):

Binding artifact (rev5)	Existing registry reused (owner law)	Verdict
Mother factory agency rows (MOW/MOT/MOIT/MOUT)	`governance_registry` `type='factory'` (Điều 37)	reuse
`produces` / `owner` factory→output edges	`governance_relations` (Điều 37)	reuse
Per-surface UI template + product rows (10 surfaces)	`design_templates` + product-from-template (Điều 28)	reuse
Per-output birth declarations	`birth_registry` + `species_collection_map` + `entity_species` (Điều 0-G/Species/29)	reuse
Per-output collection registration	`collection_registry` via `DOT-COL-REGISTER` + `dot-species-map` (Điều 36; not the non-existent `DOT-COLLECTION-CREATE`)	reuse
Factory jurisdiction (Layer A)	`law_jurisdiction` (Phạm vi, Điều 37)	reuse
Human-org-role visibility (Layer B)	Directus role/policy + field allowlist (Điều 28 Appendix) + Điều 32	extend + flag future law

The only flagged duplicate-ownership / future-law need is the human-org-role/permission law (staff/dept-lead/super-admin scoping is not owned by Điều 37 — see 10-… §2.3 D-1 + §10.2.1). It is assigned to a separate future macro, not absorbed silently.

§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

Survey sequence (rev4 MP-D22 — three surveys before the Phase 0/1 ordering decision):

1a. Run Candidate Registry Survey (G7) — field_registry / input_form_registry / output_table_registry / dot_function_registry (§S16). Macro IU_4MOTHERS_CANDIDATE_REGISTRY_SURVEY_DOCUMENT_ONLY_*X. 1b. Run Tier Registry Survey — T6/T5/T4/T3 sources (domain/company/department/specialty — existing vs paper) before MOW canvas Phase 2 (MP-D12; 08-… §11; 09-… §3.3). Macro IU_4MOTHERS_TIER_REGISTRY_SURVEY_DOCUMENT_ONLY_*X. 1c. Run Governance Ops Survey — existing task queues / AI-task+agent-run tables / governance views/logs / heartbeat / dashboards / VPS observability tooling, before cockpit + agent-ops implementation (MP-D22; 09-… §9). Macro IU_4MOTHERS_GOVERNANCE_OPS_SURVEY_DOCUMENT_ONLY_*X. 1d. Run Cross-Law Binding Readiness check (MP-D23..D26; rev5) — read-only shape check of design_templates + product-from-template (Điều 28), birth_registry + species_collection_map + entity_species (Điều 0-G/Species), collection_registry (Điều 36), and governance_registry type='factory' + governance_relations + law_jurisdiction (Điều 37) — to confirm each Mother surface can be born as a template/product and each output can be born under Điều 0-G/36 before any factory implementation. Folds into surveys 1a–1c; produces the cross-law binding section of the survey report(s). Also confirms HC-REG/HC-SCHEMA are live. Output flags the human-org-role/permission law (10-… §10.2.1) as a separate future macro. (10-… §3–§6.) 1e. IU substrate readiness gate (Rev4 reviews Gate A). Per knowledge/dev/reports/architecture/iu-4mothers-master-design-rev4-gpt-review-iu-centered-roadmap-2026-05-28.md + iu-roadmap-review-after-master-design-rev4-gpt-2026-05-28.md: do not start MOW/MOT/MOIT/MOUT factory implementation until IU substrate is production-ready. Run IU_CORE_PROCESS_BRICK_READINESS_AND_GAP_SURVEY_DOCUMENT_ONLY_3000X and finish IU tests b–f first.

Then foundation gaps:

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). MP-D22 three-survey sequencing present in §S20.1 (Candidate Registry → Tier Registry → Governance Ops survey before Phase 0/1 ordering). A6. Reversibility (Điều 30) is part of every phase. A7. (rev4 MP-D16..MP-D22) §S23 readiness items + §S18 patched registries (governance_problem*, suppression/SLO policies, kaizen lifecycle + duplicate detector, direct-canonicalization gate + security classification); no new Council fork; survey-required items flagged. A8. (rev5 MP-D23..MP-D30) §S24 readiness items + §S18 rev5 reuse-only table (no new tables; bindings are rows in design_templates/birth_registry/collection_registry/governance_registry) + §S20.1 step 1d Cross-Law Binding Readiness survey + step 1e IU-substrate gate; one candidate future law flagged (human-org-role/permission, 10-… §10.2.1); all other items within existing law boundaries.

§S22. MP-D11..MP-D15 readiness items (rev3 addendum)

The MP-D11..MP-D15 patches (08-…) introduce new readiness work. None of it is an Open Decision (no fork to resolve at the Council level), but each is a paper-only design dependency that needs a Phase 0/1/2 macro to land.

Readiness item	MP	Phase impact	Acceptance
Tier registry survey (T6/T5/T4/T3)	MP-D12	Pre-Phase-2 survey macro	Each tier source confirmed: existing rows? extension required? paper-only-new? Output as `09-tier-registry-survey.md`.
`input_routing_policy` + `input_submission` schema + gateway service skeleton	MP-D11	Phase 1	Paper schema landed; gateway skeleton (Node service) routes Nuxt → staging; direct vs workflow branch executes per config.
`audio_file_registry` + `attachment_registry` + transcription / indexing worker classes	MP-D11 / MP-D13	Phase 2	File registries exist; worker classes registered in `executor_class_registry`; events emit per `03-…` §3.4a.
`task_template` + `assignee_policy` + `deadline_policy` + `escalation_policy` registries	MP-D14	Phase 2	Four registries land with paper DDL; first task_template row materializes a JFT task via trigger subscription. Idempotency `(task_template_id, trigger_event_id)` enforced.
MOW Hierarchy Canvas T6→T1 component + tier permission filter	MP-D12	Phase 2 (after tier survey)	Same `<MowHierarchyCanvas>` renders all six tiers; backend predicates enforced.
Inline Kaizen UX + auto-context capture	MP-D13	Phase 2	Five-decision UI; gateway populates `captured_context_jsonb` per `08-…` §5.3; routing per `input_routing_policy`.
Governance Cockpit panels + AI/Agent Ops Console	MP-D15	Phase 2	11 cockpit panels + Agent Ops Console wired; MP-D9 evidence rule enforced; no raw event tail.
Kaizen quality metrics views	MP-D15	Phase 2	`vw_governance_kaizen_*` deliver submission rate / approval rate / duplicate rate / time-to-decision / merge rate / audio_share / ai_share.
OSS observability adapter slots (Prometheus / OTel / Jaeger / Tempo / Loki / Grafana / Langfuse / Helicone / Phoenix Arize)	MP-D15	Phase 4+ (gated by Gate A + B + Council)	`external_tool_registry` row with SoT-pointback; no final pick in this macro.

Open decisions introduced (genuinely new forks): none. Every MP-D11..MP-D15 item resolves within existing law boundaries (Điều 28 / 30 / 31 / 32 / 33 / 35 / 37 / 38 / 39 / 45) + future Điều XX referent. The work shape is paper-only forward sequencing, not a Council fork.

Sizing defaults (initial, tunable Phase 1):

event_payload.max_size_bytes.input.* = 4 KB.
staging.raw_text.max_bytes = 64 KB.
staging.audio.max_seconds = 180.
staging.attachments.max_count = 5.
dot_config ai_summary.min_confidence.<category> default = 0.6 (MP-D9 binding).

§S23. MP-D16..MP-D22 readiness items (rev4 addendum)

The MP-D16..MP-D22 patches (09-…) are second-order governance/operability/observability hardening. None is a new Open Decision (no Council fork); each is paper-only or survey-only forward work within existing law boundaries + future Điều XX referent.

Readiness item	MP	Phase impact	Acceptance
Điều 5 ↔ T6→T1 mapping + per-surface readiness matrix	MP-D16	Documentation now; gates Phase 2 surface scheduling	No Tầng-4/5 surface scheduled on a missing Tầng-1/2/3 substrate (`09-…` §3.3). Two axes never conflated.
`governance_problem` + `governance_problem_event_link` + `governance_problem_assignment` + `governance_suppression_policy` + `governance_slo_policy`	MP-D17	Phase 1/2 (after Governance Ops Survey)	Paper registries land; problem rows carry refs/impact only; remediation = separate change + `approval_id`; no `closed` without `verified`; auto-resolve needs source event.
Kaizen review lifecycle + duplicate detector + anti-noise controls + metrics	MP-D18	Phase 2	`kaizen_lifecycle_state` + `fn_kaizen_duplicate_cluster` land; user flow unchanged (5 clicks); rejections friendly; merged duplicates credit contributor.
Direct canonicalization allow/deny gate + data lineage + retention/PII	MP-D19	Phase 1/2	`worker.canonicalizer` gate enforces allow/deny; `input_submission.security_classification` + lineage pair + retention config land; below-threshold transcription → human review.
Minimum Observability Profile	MP-D20	Phase 1+ (metrics wired progressively; gap declared if `not_yet_wired`)	Every surface exposes the §12.1 (`03-…`) metric set or declares `not_yet_wired`; human-visible vs machine-only split; freshness rules; no auto-resolve without source event.
Raw PG-event tool reconciliation	MP-D21	Documentation now	Each raw-doc tool reconciled to verdict + adapter label + "may NOT" boundary (`05-…` §7 / `09-…` §8); no final pick.
Governance Ops Survey + three-survey sequencing	MP-D22	Pre-Phase-1/2 survey macro	`IU_4MOTHERS_GOVERNANCE_OPS_SURVEY_DOCUMENT_ONLY_*X` runs after Candidate + Tier surveys, before cockpit/agent-ops build; output `<NN>-governance-ops-survey.md`.

Open decisions introduced (genuinely new forks): none. Every MP-D16..MP-D22 item resolves within existing law boundaries (Điều 5 / 7 / 28 / 30 / 31 / 32 / 33 / 35 / 37 / 38 / 39 / 45) + future Điều XX referent.

Survey-required (not yet confirmed live), to be resolved by the Governance Ops Survey + Tier Registry Survey:

ai_tasks / agent_run table existence + shape — not confirmed live (historical AI dispatch went through an ops connector that returned a connector/DISABLED error per KB gpt-dispatch-attempt-agent-readonly-investigation-iu-current-position-2026-05-14.md). Treat as candidate_requires_survey.
"M-005 task orchestration" artifact — not found in KB; Governance Ops Survey confirms existence.
T6/T5/T4/T3 tier sources (domain/company/department/specialty) — survey_required; multi-domain infrastructure itself is a known_gap (5-layers TD-086).
State machine registry (G6/OD9) not yet deployed (Tầng-3 gap) — blocks T2/T1 runtime in the readiness matrix.

§S24. MP-D23..MP-D30 readiness items (rev5 addendum)

The MP-D23..MP-D30 patches (10-…) are the final pre-approval cross-law / industrial-birth / object-factory hardening. None is a new Open Decision; each is paper-only or survey-only forward work that reuses existing law registries (Điều 28 / 0-G / 29 / 36 / 37 / 32 / 35) — see §S18 rev5 reuse table.

Readiness item	MP	Phase impact	Acceptance
Bind every 4 Mothers UI surface to Điều 28 `design_templates` + product-from-template	MP-D23	Pre-Phase-2 (Candidate-registry + cross-law survey)	Each surface has a `design_templates` row + product record; lifecycle `draft→testing→active` + 8-key checklist + 5/5 tests; coverage scanner 0 outside-registry; field allowlist (cockpit/AI-ops); Custom Code Registry entry for any new renderer.
Birth/collection/species protocol for Mother outputs (Industrial Birth Contract)	MP-D24	Phase 1/2 (each output born when promoted from paper)	Every output has `birth_registry` + `collection_registry` + species mapping + `governance_role` + `composition_level`; created via `DOT-COL-REGISTER` + `dot-species-map` + DOT+APR (never raw psql); `HC-REG`/`HC-SCHEMA` clean.
Register each Mother as Điều 37 `factory` agency + `produces`/`owner` edges	MP-D25	Phase 1 (Governance Ops survey confirms shape)	`governance_registry` `type='factory'` row per Mother + `output_target` + `governance_relations` edges; `can_create`/`can_reference`/`must_not_own` enforced.
Jurisdiction binding (Layer A Điều 37 + Layer B Directus/Điều 32)	MP-D26	Phase 1/2	`law_jurisdiction` per factory; Directus role + field allowlist enforce human-role visibility backend-first; jurisdiction matrix per object type. Future need: human-org-role/permission law (`10-…` §10.2.1).
NT14 execution-traceability matrix maintained for each new object class	MP-D27	Documentation now; gates each Phase build	No object class implemented without filling its `10-…` §7 traceability row.
Assembly-first reuse decision tree applied before any new artifact	MP-D28	Every Phase	Q0–Q7 walk recorded per new artifact; rev5 adds no new tables (reuse-only).
No-"đẻ rơi" factory safety gates + reject list wired to scanners	MP-D29	Phase 1+ (scanners progressively wired; gap declared if `not_yet_wired`)	Orphan/phantom/nhầm-chuồng/un-templated/un-certified count = 0 for the 4 Mothers namespace via `DOT-ORPHAN-SCANNER`/`DOT-COL-ORPHAN`/`HC-REG`/`HC-SCHEMA`/`DOT-MISCLASS-SCANNER`/`DOT-template-coverage`/`birth_registry.certified`.
Agent self-review carried in the design package	MP-D30	Now	`10-…` §10 PASS/PARTIAL/BLOCKED + exact gaps recorded; overall PARTIAL (human-org-role law gap).

Open decisions introduced (genuinely new forks): one candidate future law — a human-org-role/permission law (D-1; 10-… §2.3 + §10.2.1). It is not an OD1-style Council fork on existing material; it is a newly-surfaced gap that no current law owns. Tracked as a separate future macro, not enacted here. All other MP-D23..D30 items resolve within existing law boundaries (Điều 7 / 28 / 29 / 30 / 31 / 32 / 33 / 35 / 36 / 37 / 38 / 39 / 45) + future Điều XX referent.

Survey-required (not yet confirmed live): design_templates current 4-Mothers coverage; collection_registry shape for proposed Mother-output collections; governance_registry factory rows for the 4 Mothers (likely absent today — paper); HC-REG/HC-SCHEMA live status. All resolved by the Cross-Law Binding Readiness check (§S20.1 step 1d).

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

§S22. MP-D11..MP-D15 readiness items (rev3 addendum)

§S23. MP-D16..MP-D22 readiness items (rev4 addendum)

§S24. MP-D23..MP-D30 readiness items (rev5 addendum)

§S3. OD3 — `executor_class_registry` ownership

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

§S13. OD13 — `dot_function_registry` ownership / naming