08 — 4 Mothers / Automation Pilot Bridge (Workstream G)

Goal

Make AX-TOPIC a practical control surface for automation — not just taxonomy — without building a workflow engine.

How AX-TOPIC drives the 4 Mothers

The axis becomes a routing key. Each routing relationship is an axis_assignment row (node_code = topic, target_type = the routed object, relation_type = the routing verb) and/or a universal_edges edge. No new engine; the Mothers read these rows.

• MOW (workflow Mother) — topic → workflow selection: axis_assignment(target_type=workflow, relation_type=routes_to). MOW picks the workflow whose topic matches the input's topic node.
• MOT (task Mother) — topic → task/template grouping: axis_assignment(target_type=task_template, relation_type=groups_under). Tasks inherit the topic of their parent IU/document.
• MOIT (improvement Mother) — topic → improvement routing: axis_assignment(target_type=improvement, relation_type=routes_to) or an approval_requests row tagged with the topic node.
• Document template selection — topic → template: axis_assignment(target_type=document_template, relation_type=selects).
• Event/staging routing — topic → event_type_registry entry: axis_assignment(target_type=event, relation_type=routes_to).
• DOT/Agent selection — topic → DOT/agent: axis_assignment(target_type in dot_tool/agent, relation_type=handled_by).

All of these are already representable in the live axis_assignment schema (target_type + target_code + relation_type) — the table was designed multi-target precisely for this.

Sample automation scenario (end-to-end, using live substrate)

Input topic candidate knowledge_graph (10 IUs already linked):

1. Input topic candidate → already present as TOPIC-CAND:knowledge_graph with 10 assignments.
2. Link to IU → live (10 information_unit rows).
3. Link to document/template → add axis_assignment(node knowledge_graph, target_type=document_template, target_code=<KG-doc-template>, relation_type=selects).
4. Route to workflow/task → add axis_assignment(target_type=workflow, target_code=<KG-enrichment-workflow>, relation_type=routes_to).
5. Create improvement proposal → file an approval_requests row (request_type=improvement) carrying the topic node in source_context.
6. Show in Registries-Pivot axis surface → already visible: the node appears in v_registries_pivot_axis_surface with count_value 10; fn_topic_node_substrate returns the full chain.

Steps 3–5 are edge/assignment inserts only — the pilot's gap, not an engine gap.

Exact rows needed for the pilot scenario

• 1 axis_assignment: knowledge_graph → document_template (selects)
• 1 axis_assignment: knowledge_graph → workflow (routes_to)
• 1 approval_requests: improvement proposal referencing the topic node These are owner-gated (they assert routing law) and are listed as the first automation-bridge work item, deferred to the next macro.

Missing registries/pivots for full automation

• Workflow/DOT/template registries exist in the system; a topic→target convention (relation_type vocabulary) needs ratifying.
• PIV-327 (workflows by topic) and PIV-328 (DOTs by topic) stay DEFER_NO_SOURCE until these assignment rows exist — once they do, the same v_axis_topic_pivots view reports them with no change.

Scope discipline

No workflow engine built. The bridge is a data convention over existing tables (axis_assignment, universal_edges, event_type_registry, approval_requests). This keeps the axis a control surface, not a parallel orchestrator.