KB-E63B

RP UI Axis — 06 Automation Bridge Row/Edge Plan

5 min read Revision 1
topic-axisautomationfour-mothersrow-edge-plan2026-06-04

06 — Automation Bridge Row/Edge Plan (Workstream E)

Principle

AX-TOPIC is a routing key, not an engine. Each routing relationship is one axis_assignment row (and/or one universal_edges edge). The 4 Mothers READ these rows. No workflow engine is built. Every pattern below is already representable in the live axis_assignment schema (node_code, target_type, target_code, relation_type, confidence, source, status, evidence_ref, approval_ref).

Minimal routing patterns (table = axis_assignment unless noted)

Pattern target_type relation_type Mother / consumer Substrate today
topic → IU information_unit tagged_topic (provenance) LIVE 25 rows
topic → document document classifies RP / docs 0 (next)
topic → document template document_template selects Document-template select 0 (next)
topic → workflow workflow routes_to MOW 0 (next) → PIV-327
topic → task template task_template groups_under MOT 0 (next)
topic → improvement improvement routes_to MOIT (or approval_requests) 0 (next)
topic → DOT/Agent dot_tool / agent handled_by DOT/Agent select 0 (next) → PIV-328
topic → event event routes_to event_type_registry route 0 (next)

Which existing table for which job

  • axis_assignment — the primary routing carrier (multi-target by design). Use for all topic→target routing rows.
  • universal_edges — use when the relationship is a graph edge needing edge_type/weight/symmetry (e.g. topic↔topic broader/narrower for the DAG; topic↔facet is already auto-managed). Edge types live: BELONGS_TO/CONTAINS auto-managed; broader/narrower/related for topic hierarchy.
  • event_type_registry — already has object_type/object_ref/owner_gov_code; a topic→event route references an event_type row; do not duplicate the registry.
  • approval_requests — carries improvement proposals; reference the topic node in source_context / entity_code.
  • existing workflow / task / template registries — referenced by target_code; the convention (relation_type vocabulary) needs ratifying, not new tables.

relation_type vocabulary to ratify (owner)

tagged_topic (live), classifies, selects, routes_to, groups_under, handled_by. These are the routing verbs; ratifying them is a one-time governance act, not code.

Concrete pilot scenario — knowledge_graph (10 IUs live)

Live today: TOPIC-CAND:knowledge_graph → 10 information_unit assignments (relation tagged_topic); resolver returns 10 IUs + 10 evidence tags. Proposed pilot rows (owner-gated, NOT inserted):

  1. axis_assignment(node='LBL-NNN'(promoted KG), target_type='document_template', target_code='<KG-doc-template>', relation_type='selects', source='proposed', status='candidate')
  2. axis_assignment(node='LBL-NNN', target_type='workflow', target_code='<KG-enrichment-workflow>', relation_type='routes_to', status='candidate')
  3. approval_requests(request_type='improvement', entity_code='LBL-NNN', title='KG enrichment route', source_context={topic:'knowledge_graph'}, status='pending') Effect once added (no view change needed): PIV-327 (workflows by topic) and PIV-328 (DOTs by topic) flip from DEFER_NO_SOURCE to computable; resolver's documents/workflows/dots_agents_events arrays populate; decision queue document_count becomes non-zero.

Mother routing read pattern (illustrative, no engine)

  • MOW input has topic T → SELECT target_code FROM axis_assignment WHERE node_code=T AND target_type='workflow' AND relation_type='routes_to' AND status='active' → run that workflow.
  • MOT task inherits parent IU/doc topic → groups_under rows give the template grouping.
  • MOIT improvement → file approval_requests carrying the topic; MOIT reads open requests by topic.

Exact rows the NEXT macro needs (deferred, owner-gated)

  • 1 axis_assignment: KG → document_template (selects)
  • 1 axis_assignment: KG → workflow (routes_to)
  • 1 approval_requests: improvement referencing KG
  • ratified relation_type vocabulary (6 verbs above) These assert routing law → owner-gated. Listed as the first work item of TOPIC_AXIS_EDGE_POPULATION_AND_AUTOMATION.

Scope discipline

No engine, no parallel orchestrator, no new tables. The bridge is a data convention over axis_assignment / universal_edges / event_type_registry / approval_requests.

Back to Knowledge Hub knowledge/dev/reports/architecture/rp-ui-consume-axis-surface-decision-queue-automation-handoff-2026-06-04/06-automation-bridge-row-edge-plan.md