Policy-constrained escalation routing¶
Evaluate authority boundaries, policy triggers, and case context to recommend the right escalation path and package the supporting rationale without executing the escalated action.
Metadata¶
- Pattern id:
policy-constrained-escalation-routing - Pattern family: Recommend / Decide / Escalate
- Problem structure: Recommendation and decision support (
recommendation-and-decision-support) - Domains: Compliance (
compliance), Operations (operations), Support (support), HR (hr)
Workflow goal¶
Determine whether a case can remain in its current queue or must be escalated, recommend the most appropriate governed route, and assemble an audit-ready packet so the authorized human decision-maker can act with clear context.
Inputs¶
Candidate case or exception¶
- Description: The request, alert-derived case, exception, or unresolved issue that may require escalation beyond the current handler's authority.
- Kind: case
- Required: Yes
- Examples:
- Customer support dispute requesting credits beyond frontline approval limits
- Workplace concern requiring escalation from local HR to an employee-relations specialist
- Operational exception that may require regional duty-manager review
Escalation policy and authority matrix¶
- Description: Routing rules, approval thresholds, segregation-of-duties requirements, and non-waivable constraints that define who may decide each class of case.
- Kind: policy
- Required: Yes
- Examples:
- Complaint classes that require compliance review within a defined SLA
- Authority matrix showing when site leaders must escalate to corporate operations
- HR policy identifying cases that must bypass line management and route to protected channels
Supporting evidence and case context¶
- Description: Facts, prior interactions, supporting records, precedent cases, and risk indicators needed to justify the recommended route.
- Kind: evidence-set
- Required: Yes
- Examples:
- Ticket history, entitlement records, and promised service terms
- Prior remediation attempts, local manager notes, and documented employee requests
- Timeline of control exceptions and linked operating impacts
Current workflow state¶
- Description: Ownership, pending approvals, existing escalations, timers, and duplicate-case state that affect whether the case should be rerouted or held.
- Kind: case-state
- Required: No
- Examples:
- Existing escalation already open with a specialist queue
- SLA timer nearing breach for a regulated complaint
- Pending local review that would become invalid if a protected category is confirmed
Outputs¶
Ranked escalation route recommendation¶
- Description: Ordered routing options showing the preferred escalation destination, confidence, policy basis, and conditions that block lower-authority handling.
- Kind: recommendation
- Required: Yes
- Examples:
- Recommend immediate routing to compliance counsel because complaint content triggers mandatory review
- Recommend escalation to employee-relations leadership instead of local HR because retaliation risk is present
Escalation packet¶
- Description: Governed case bundle containing evidence, unresolved uncertainty, policy citations, and the minimum information the receiving authority needs to decide the next step.
- Kind: case-packet
- Required: Yes
- Examples:
- Specialist-support handoff packet with contract terms, prior commitments, and requested exception
- Operations escalation brief with site impact, prior mitigations, and authority-threshold rationale
Routing decision log¶
- Description: Durable log of policy checks, route comparisons, confidence limits, and human handoff events for each escalation recommendation.
- Kind: audit-log
- Required: Yes
- Examples:
- Record showing why a case bypassed local review and who accepted the escalated handoff
- Log of competing routes considered and why one authority path was preferred
Environment¶
Operates in governance-sensitive service, people, compliance, and operating workflows where the core problem is choosing the right escalation authority quickly and defensibly before a case is mishandled or delayed.
Systems¶
- Case management and ticketing platforms
- Policy, procedure, and authority-matrix repositories
- Evidence stores and communication history systems
- Workflow routing and queue-management tools
Actors¶
- Frontline analyst or case owner
- Escalation coordinator or specialist reviewer
- Compliance, HR, support, or operations authority
- Human decision-maker receiving the escalation packet
Constraints¶
- The workflow must stop at recommendation, routing, and escalation packaging rather than executing the receiving authority's next action.
- Non-waivable policy triggers must remain explicit and must not be softened by contextual heuristics.
- Sensitive case details should be minimized to what the receiving authority needs for a governed decision.
- Duplicate or concurrent escalations must preserve lineage so ownership confusion is auditable later.
Assumptions¶
- Policies and authority mappings are accessible in a form that can be checked against current case facts.
- Human authorities remain accountable for accepting, rejecting, or redirecting the escalation recommendation.
- Case systems can preserve routing history and evidence references across handoffs.
Capability requirements¶
- Retrieval (
retrieval): The workflow needs policy text, case history, prior escalations, and supporting records before it can justify a route recommendation. - Synthesis (
synthesis): Escalation routing depends on combining case facts, authority boundaries, and unresolved questions into one decision-ready packet. - Recommendation (
recommendation): The central output is a ranked escalation path with rationale, not a completed downstream action. - Policy and constraint checking (
policy-and-constraint-checking): Routing quality depends on enforcing mandatory escalation triggers, approval limits, privacy constraints, and segregation-of-duties rules. - Verification (
verification): Case facts, protected attributes, threshold calculations, and precedent fit must be checked before the workflow recommends bypassing or invoking a higher authority. - Coordination (
coordination): Specialized intake, evidence review, policy interpretation, and packet assembly roles need shared state so the receiving authority sees one coherent escalation story. - Memory and state tracking (
memory-and-state-tracking): The workflow must remember prior routing decisions, active escalations, reviewer feedback, and SLA timers across iterative case updates. - Exception handling (
exception-handling): Missing evidence, conflicting policies, and ambiguous authority boundaries must lead to explicit uncertainty or higher escalation rather than silent local handling.
Execution architecture¶
- Orchestrated multi-agent (
orchestrated-multi-agent): Separate intake, evidence-review, policy-checking, and escalation-packaging roles are often worth orchestrating explicitly so routing stays explainable, policy-bounded, and fast under case volume. - Human in the loop (
human-in-the-loop): Human authorities remain embedded in the normal loop because accepting an escalation path, overriding it, or sending the packet onward is itself a governed decision.
Autonomy profile¶
- Level: Recommendation only (
recommendation-only) - Reversibility: Routing scores and packet contents can be recomputed, but misrouting or delaying a sensitive escalation may only be partially reversible after SLA breaches, employee harm, customer dissatisfaction, or control failures occur.
- Escalation: Escalate whenever authority is ambiguous, non-waivable policy triggers are implicated, confidence in the receiving route is low, protected channels may be required, or the next step would create material operational, compliance, customer, or people consequences.
Human checkpoints¶
- Confirm whether the recommended authority path should be accepted, redirected, or rejected before any downstream action or commitment occurs.
- Review cases with conflicting policy signals, protected attributes, or incomplete evidence before the workflow may recommend local handling.
- Approve material changes to routing thresholds, mandatory-escalation triggers, or packet contents before they affect live cases.
Risk and governance¶
- Risk level: High (
high) - Failure impact: Misrouting, delaying, or under-escalating a case can create meaningful compliance exposure, employee-relations harm, customer-impact escalation, or operational breakdown, while over-escalation can overwhelm specialist queues and degrade trust in governance controls.
- Auditability: Preserve source case facts, policy versions, route comparisons, threshold checks, packet contents, human overrides, and handoff timestamps for every escalation recommendation.
Approval requirements¶
- Human acceptance is required before the recommended route changes case ownership, exposes sensitive details to a new authority, or triggers consequential downstream handling.
- Policy owners must approve material changes to authority matrices, mandatory-escalation rules, and protected-channel logic.
Privacy¶
- Minimize personal, customer, and sensitive operational details in escalation packets to the least information needed for the receiving authority to decide.
- Apply retention, access, and redaction controls that match the case class and governing obligations.
Security¶
- Restrict routing and packet-assembly permissions so the workflow cannot silently alter policy sources or downstream authority records.
- Log privileged overrides, manual reroutes, and policy exceptions in durable reviewable records.
Notes: High-risk governance fits because the workflow shapes who sees and decides sensitive cases, even though it remains bounded at recommendation and governed routing rather than execution.
Why agentic¶
- Good escalation routing requires comparing policy triggers, case context, and authority boundaries instead of applying one static decision tree.
- The workflow benefits from specialized agents coordinating evidence review, policy interpretation, and packet assembly while preserving one auditable case state.
- Safe performance depends on recognizing when uncertainty itself is grounds for higher escalation instead of forcing a brittle local answer.
Failure modes¶
A case that requires mandatory escalation is recommended for local handling¶
- Impact: Sensitive or regulated matters remain with an unauthorized handler, causing delayed response, control failure, or harm to affected people.
- Severity: high
- Detectability: medium
- Mitigations:
- Encode non-waivable escalation triggers as explicit blocking conditions rather than weighted preferences.
- Replay historical mandatory-escalation cases to verify they still route upward under current policy versions.
The workflow recommends the wrong escalation authority¶
- Impact: The case reaches a team that lacks jurisdiction or context, creating delay, repeated handoffs, and audit confusion.
- Severity: high
- Detectability: medium
- Mitigations:
- Compare recommended routes against the current authority matrix and active ownership state before surfacing them.
- Preserve alternate-route rationale so human reviewers can detect misfit before accepting the handoff.
Over-escalation floods specialist queues¶
- Impact: High-value review channels are saturated, slowing truly urgent cases and eroding trust in the routing logic.
- Severity: medium
- Detectability: high
- Mitigations:
- Measure false-escalation patterns by case class and tune thresholds conservatively.
- Require explicit rationale when weak signals are treated as sufficient for higher-channel routing.
The workflow drifts into collaboration or execution beyond the routing boundary¶
- Impact: Family boundaries blur, human authority weakens, and downstream actions occur without the intended decision checkpoint.
- Severity: medium
- Detectability: high
- Mitigations:
- Keep outputs limited to route recommendations, escalation packets, and routing logs.
- Separate downstream investigation, response, and remediation tooling from the escalation-routing workflow.
Evaluation¶
Success metrics¶
- Rate at which accepted recommendations match the ultimately correct authority path without avoidable rerouting.
- Time from case qualification to delivery of a complete escalation packet to the authorized reviewer.
- Frequency with which mandatory-escalation triggers are caught before local handling or SLA breach.
Quality criteria¶
- Each recommendation shows why the preferred route fits policy, why lower-authority handling is insufficient, and what uncertainty remains.
- Packet contents remain bounded to the information needed for downstream human decision-making rather than operational execution.
- Routing history and human overrides stay visible enough to reconstruct who decided what and when.
Robustness checks¶
- Test conflicting policy clauses and ensure the workflow surfaces uncertainty or higher escalation instead of inventing a confident local answer.
- Test stale ownership state, duplicate cases, and concurrent escalations to verify routing lineage remains coherent.
- Test sensitive-case classes that require protected channels and confirm packet minimization and authority checks still hold.
Benchmark notes: Evaluate both under-escalation harm and specialist-queue burden; a quieter system is not better if policy-bound escalations become easier to miss or delay.
Implementation notes¶
Orchestration notes¶
- Keep case intake, evidence review, policy interpretation, route comparison, and packet assembly as explicit coordinated stages over shared case state.
- Preserve a clean handoff boundary so receiving authorities own any later investigation, remediation, or external communication.
Integration notes¶
- Common implementations integrate ticketing, case management, policy repositories, communication history, and governed routing queues.
- Keep the pattern neutral about specific ITSM, HR case-management, or compliance workflow products.
Deployment notes¶
- Start with case classes where misrouting is costly and authority matrices are already well defined enough to audit.
- Monitor reroute rates, mandatory-escalation misses, and reviewer overrides continuously because policy drift can quickly degrade trust.
References¶
Example domains¶
- Compliance (
compliance): Recommend whether a complaint or control exception should route to compliance counsel, a regulator-response team, or remain with local reviewers based on mandatory triggers. - Operations (
operations): Route a site-level service failure exception to regional operations leadership when local managers lack authority to accept the customer or safety impact. - Support (
support): Escalate a frontline case to a specialized recovery, billing, or executive-support queue when contract terms or customer-impact thresholds exceed local authority. - HR (
hr): Recommend protected escalation of an employee-relations case away from local management when policy requires a confidential review path.
Related patterns¶
- Deal desk recommendation support (adjacent-to)
- Both patterns support governed choice, but this one centers on routing the case to the right authority rather than structuring a commercial recommendation.
- Browser-based form completion with approval gates (hands-off-to)
- Once a human accepts the escalation path, downstream systems may use approval-gated execution patterns to submit or record the authorized next step.
Grounded instances¶
- Regulatory incident breach-notification escalation routing
- Executive retaliation concern protected-review escalation routing
- Regional cold-chain compressor failure escalation routing
- Sovereign-cloud storage-corruption restricted-artifact escalation routing
Canonical source¶
data/patterns/recommend-decide-escalate/policy-constrained-escalation-routing.yaml