Branch D — Process / Workflow Design Inventory & Gap

Doc 04 (2026-05-29)

Question: where do process/workflow designs live today, and in what shape? Finding: fragmented across five stores, and the one PG substrate that exists is NOT IU-bound — it stores body text inline, contradicting the Rev2 IU-centered doctrine. This is the core motivation for a workflow design registry (Doc 05/06).

1. The five stores (where process designs live)

Store	What lives here	Governed?	Health/status?	Example
PG workflow substrate	workflows(2), workflow_steps(70), workflow_step_relations(80), workflow_categories(3), workflow_change_requests(3)	partial (_dot_origin, status, change_requests w/ approved_by/dsl_diff)	per-row status only	the live 2 workflows / 70 steps
DOT commands	compose-from-steps (dot_iu_create_workflow_from_steps→fn_iu_compose), structure ops	yes (catalog + run-log)	run-log	A-pack 04
KB reports / design docs	Rev2 design, requirements, macro reports, pilot runbooks	doc-only (KB revisions)	none (prose)	v0.6-iu-4mothers-event-foundation-rev2/
Agent / user paste-prompts	the macro mission prompts themselves; operating protocols	none (text)	none	this mission's prompt; pilot day1 runbook
Code / functions	fn_cut_* pipeline, route worker, emit — process logic embedded in PL/pgSQL	yes (functions)	gate/run	fn_cut_complete, fn_iu_route_worker_run

2. The IU-binding gap (live-confirmed)

Live introspection of the workflow substrate columns:

Table	Body/narrative columns (inline text)	IU-binding columns
workflows	title, description, **bpmn_xml**, **narrative**, process_code	0
workflow_steps	title, description, **trigger_in_text**, **trigger_out_text**, config	0
workflow_step_relations	relation_type, condition_expression, label	0
workflow_change_requests	dsl_diff, schema_warnings, description	0

iu_binding_cols = 0 on every workflow table. The substrate predates the Rev2 design and stores process narrative as inline bpmn_xml / narrative / description / trigger_*_text. The Rev2 doctrine (REV2-04 §2.1, §2.7) is explicit: "there is no 'workflow artifact track separate from IU'… workflow_step_def has no body column; narrative comes only from a bound IU/bundle." ⇒ the live substrate violates IU-centered design.

3. Inventory model — the dimensions a design registry must capture

For each process the GPT-DIR asks ten questions. Current answerability:

Dimension	Where today	Answerable now?
storage location	scattered (5 stores)	partially
exists in reports	KB docs	yes (prose)
exists in code	fn_* functions	yes
exists as DOT	dot_iu_* / catalog	yes
exists as manual paste	agent prompts	no registry
automatic vs human-in-loop vs agent-in-loop	implied by actor_type (workflow_steps), trigger config	partial
health / status	row status, health_dot (governance)	partial
last review date	workflow_change_requests.applied_at	partial
improvement suggestions (Kaizen)	workflow_change_requests (dsl_diff)	yes (mechanism exists)
domain / tree axis classification	workflow_categories (parent_id/level)	partial (not IU axes)

4. Gap statement

1. No single registry of "process designs as governed IU-backed blueprints." Five disjoint stores; no join key; workflow_steps carry inline body instead of IU refs.
2. No automation-level / loop-type taxonomy. actor_type exists on steps but there is no first-class field for automatic / human-in-loop / agent-in-loop, nor a health traffic-light per design.
3. No design↔runtime link. Rev2 separates workflow_def (blueprint) from workflow_run (execution); live workflows conflates them and has no workflow_run/step_run.
4. Improvement loop is present but under-used. workflow_change_requests (with dsl_diff, approved_by, applied_at) is a real Kaizen channel — reuse it, don't rebuild.
5. Migration debt. The 2 workflows / 70 steps / 80 relations must move from inline bpmn_xml/narrative/trigger_*_text to IU-bound bodies before they can be the "smart-brick" substrate.

Do not solve all of this here. The decision (MOW vs MOWD) is Doc 05; the target schema is Doc 06; scale/UI is Doc 07.