Branch F — Workflow Design Blueprint Schema (DESIGN ONLY)

Doc 06 (2026-05-29)

Scope: a minimal PG-first, IU-bound, proposal-gated blueprint shape for the MOW design sub-registry (Doc 05). No tables are created here. This is a design proposal for Council/APR; it reuses existing substrate per Đ7.

Core invariants the shape must honour:

• IU-centered: a blueprint and its steps carry no inline body — narrative comes only from a bound IU/bundle (REV2-04 §2.1). This is the fix for the Doc 04 gap.
• PG-first (NT13): every binding is a PG row driving behaviour; no behaviour in code/text.
• Def vs run separation: blueprint (def) links to but does not contain runtime state (workflow_run/step_run).
• Proposal-gated (Đ32/Đ39): changes via workflow_change_requests + APR; AI proposes, human approves (ABox/TBox boundary).
• Reuse: extend workflows/workflow_steps/workflow_step_relations/workflow_categories/workflow_change_requests rather than create a parallel set; the "new" is binding columns + a thin header.

1. workflow_design (blueprint header) — reuse/extend workflows

Field	Type	Notes
workflow_design_id	uuid PK	the blueprint id
code	text unique	PREFIX-NNN, birth-registered (Đ0-G/Đ36)
title	text	label only — no body
iu_header_ref	uuid → information_unit	optional IU holding the design's narrative/spec (the body)
domain_axis_ref	(axis B classification)	reuse IU axis B; not a new taxonomy
tree_axis_ref / category_id	→ workflow_categories	hierarchy (domain→company→dept→specialty)
owner_gov_ref	text → governance_registry	GOV-MOW (single owner)
governing_law_ref	text → normative_registry	future Điều XX (app layer)
status	enum	born→active→deprecated→retired (Đ36 soft-delete only)
automation_level	enum	automatic / human_in_loop / agent_in_loop / mixed
health_dot	text → dot catalog	Tier-A health command (traffic-light source)
last_review_at	timestamptz	for review-age filter
review_decision_ref	uuid	Đ32 approval binding
version / superseded_by	int / uuid	versioning; pin policy mirrors IU

2. workflow_design_step — reuse/extend workflow_steps

Field	Type	Notes
step_id	uuid PK
workflow_design_id	uuid FK	parent blueprint
step_key / sort_order	text / int	order
step_kind	enum	{iu, bundle, assembly_view, task_template} — exactly one binding ref non-NULL (REV2-04 §3.7)
iu_unit_ref	uuid → information_unit	the body binding (fixes inline-text gap)
pinned_iu_version_ref	uuid → iu_version	version pinning (default pin; migration needs APR)
bundle_ref / assembly_view_ref / task_template_ref	uuid	alternative bindings
trigger_in_config	jsonb	preconditions: step_state / trigger_event / time_gate (NOT free text)
trigger_out_config	jsonb	postconditions: emit_events / output_contract_ref / next_step_signals
actor_type	enum	automatic / human / agent

Migration: existing workflow_steps.trigger_in_text/trigger_out_text/description → structured config + bound IU bodies.

3. workflow_design_step_relation — reuse workflow_step_relations

from_step_id, to_step_id, relation_type, condition_expression, label, sort_order. (Already exists; no change needed beyond FK to design steps.)

4. workflow_design_trigger (or step-level config) — per REQ §5.3

trigger_type ∈ {schedule, prior_output, manual, combo(AND/OR)}, config jsonb. Referenced events MUST exist in event_type_registry (register-before-emit, Đ45).

5. Binding tables (references — never ownership)

Binding	Target (reuse)	Rule
dot_refs[]	dot_iu_command_catalog / dot_tools	which DOTs the step runs
sql_link_refs[]	iu_sql_link	IU↔SQL data binding
event_refs[]	event_type_registry	trigger in/out events
code_refs[]	function/file refs	PL/pgSQL or app code the step invokes
output_report_refs[]	design_templates / MOUT	reports/outputs produced
runtime_status_link	workflow_run / step_run	def↔run link (read-only projection)
kg_relation_refs	iu_relation / universal_edges	"used-together" KG (provenance-or-quarantine Đ39)

6. Review & improvement (Kaizen) — reuse workflow_change_requests

change_type, title, dsl_diff, schema_warnings, suggested_actor_type, status, approved_by, applied_at, task_id. AI writes proposals; human approves via Đ32. improvement_suggestions surface here, never auto-applied (Đ39 golden rule).

7. What is explicitly NOT in this shape

• No body columns on design/step (IU-bound only).
• No runtime execution state (lives in workflow_run/step_run).
• No new governance spine — owner is GOV-MOW; no MOWD factory row.
• No DDL executed — this is paper-only until Candidate-Registry-Survey-style verification + APR (Đ32) + birth (Đ0-G/Đ36). Per MP-D7, no executable artifact may reference these table names by literal until the registry is verified_live.

8. Relationship to existing tables (assembly map)

New concept	Assembly decision (Đ7 tree)
workflow_design header	extend workflows (+ IU header ref, owner, health, automation_level)
workflow_design_step	extend workflow_steps (+ iu_unit_ref, pinned version, structured trigger config)
step relations	reuse workflow_step_relations as-is
categories/tree	reuse workflow_categories
change/Kaizen	reuse workflow_change_requests
bindings	new binding rows in existing registries (iu_sql_link, event_type_registry, dot catalog)

⇒ The blueprint is largely an extension + IU-binding migration of the existing workflow substrate, not a greenfield schema — exactly what Đ7 / Rev5 "no new tables of its own" prescribes.