08 — Four Mothers & Automation Integration (Workstream F)

Goal: position the topic axis as a control surface for workflow automation, not just classification.

The 4 Mothers (recap)

• MOW — Mother of Workflow (workflow canvas; workflows, workflow_steps, BPMN, Điều 34).
• MOT — Mother of Task (task templates / JFT; tasks, checkpoints). Đ45: MOT is not an executor; the queue carries signal, not data.
• MOIT — Mother of Improvement / Intake (improvement proposals; workflow_change_requests PIV-006).
• MOUT — Mother of Output / render (Registries-Pivot display owner, GOV-MOUT).

Topic axis ↔ Mother mapping

Mother	Topic axis connection	Edge store	Drives
MOW	a workflow declares the topic(s) it operates on	universal_edges workflow↔topic	workflow selection: "show workflows for topic X"; auto-suggest workflow templates by topic
MOT	task templates / JFT grouped by topic	universal_edges task↔topic; tasks	task grouping & routing: tasks inherit topic from their workflow; topic drives assignment buckets
MOIT	improvement intake routed by topic	workflow_change_requests ↔ topic	improvement routing: a proposal tagged topic:governance routes to the governance owner
MOUT	renders the topic axis map	v_registries_pivot_axis_surface	navigation & cross-check: humans/DOTs verify coverage per topic
Document building	document templates selected by topic	knowledge_documents ↔ topic	template selection: building a doc on topic X pulls the IUs/sections tagged X

Where topics drive automation (answer to macro Q within §9)

1. Workflow selection — topic → candidate workflows (MOW). A user picks a topic; the system proposes the workflows that operate on it.
2. Document-template selection — topic → document templates + the IU/section set tagged with that topic (the document-building corpus). This is the bridge from "information pieces mapped by topic" to "documents built from those pieces."
3. Task grouping — tasks inherit topic from workflow; topic becomes a grouping/assignment dimension in MOT.
4. Improvement-proposal routing — MOIT intake routed to the topic's governance owner (governance_object_ownership).
5. Governance review — a topic with governance_status=owner_gap or orphan/phantom warnings (PIV-329/330/332) raises a review item; DOTs scan→propose→APR→apply per the coverage-DOT lifecycle (Điều 35).

DOT / Agent / event control via topic

The topic axis is a control surface because universal_edges lets DOTs, Agents, and event types attach to topics (PIV-328). This enables: "which DOTs touch topic X," "which events fire for topic X," "which Agent owns topic X." Combined with the coverage-DOT lifecycle, a topic becomes a unit of automated control, not just a label.

Missing registries / pivots to support config-generated workflows

• axis_assignment (doc 06) — needed so documents/workflows/tasks (not just IUs) can carry topic membership with confidence.
• Edge population — universal_edges rows linking topics↔workflows/DOTs/events do not exist yet; they must be created under governance (owner-gated), not auto-faked.
• Topic→template binding — a binding table or axis_registry.config entry mapping a topic to its document/workflow templates (future; deferred until topic axis is populated).

Honest status

The integration is architecturally mapped but not wired: the edge stores (universal_edges) and the assignment substrate are live, but the rows (topic↔workflow, topic↔DOT, topic↔template) do not exist and FAC-08 has no nodes. So the topic axis can be positioned as a control surface now; it functions as one only after topics are populated and edges are created under governance (doc 09 next macro). No automation wiring is faked in this session.

Workstream F completion: topic axis is positioned as the control surface bridging information pieces → documents → workflows → tasks → improvement → governance, with the exact edge/assignment gaps named.