Skip to content
MirrorFirm

Why test escalation separately from approve and decline decisions?

A correct-looking outcome can still be a process breach, so escalation tests check who is allowed to decide as well as what the decision is.

**Why not just test whether the agent approves or declines correctly?**

Because a correct-looking outcome can still be a breach. An agent that approves a case it had no authority to approve may reach the same answer a senior reviewer would, yet the process has failed. Escalation tests check who is allowed to decide, not only what the decision is.

**What makes escalation different from other routing?**

The trigger depends on policy and context. A limit may apply to a single request, to aggregate exposure, to a product type or to a risk grade. Exceptions and temporary delegations alter it. Routing also has a target: the next reviewer must hold enough authority, be available and not be conflicted with the case.

**Does the agent decide whether to escalate, or follow a flag?**

Both are worth testing. Some task packs can put an explicit escalation flag on the case, while others leave the agent to infer the need from records. The second is closer to how connected agents are actually deployed.

**What goes wrong when escalation is poor?**

- cases stall in a queue where no one can approve them - the senior reviewer repeats work the first reviewer already did - unauthorised approvals appear in the audit trail - needless escalations add load to senior staff

A release can include cases for each of these failure modes, generated rather than drawn from real records. Buyers should inspect any sample for grounding and disclosure risk.

Scoring only the final outcome hides unauthorised approvals; scoring the routing decision exposes them.

Audience:
Agent developers
Content type:
FAQ
Buyer question:
What it is and why it matters

Content release: r-a220eb6e099b243b

More on Credit escalation