Runbook Domain Router

Workflow

1. Extract domain signals from the request: identify platform mentions, tool names, object types (Lead, Contact, Opportunity), and lifecycle stage (audit, build, incident, dedup).
2. Score domain candidates: assign a confidence score (0–1) to each candidate runbook based on signal match strength; a single strong platform mention scores 0.8+.
3. Apply the routing table: match the highest-confidence candidate against the domain routing table; select the First Runbook if confidence > 0.7, present alternatives if confidence is 0.5–0.7.
4. Handle low-confidence routing: if confidence < 0.5 or the request spans 3+ domains, surface the top 2–3 runbook candidates with their confidence scores and ask the user to confirm before proceeding.
5. Produce the ordered route: output a ranked list: primary runbook, alternatives, and escalation path (e.g., opspal-core:intake for highly ambiguous multi-domain requests).
6. Log the routing decision: append the route decision to the session's routing audit trail with request summary, domain scores, and selected runbook.

Safety Checks

• Require user confirmation when confidence is below 0.6 — do not silently execute a low-confidence runbook
• Prefer read-only or diagnostic runbooks over build/deploy runbooks when intent is ambiguous
• Preserve an audit trail of every route decision including the alternatives considered