Escalation Logic
Our reliability layer determines when a workflow should stop normal execution and move to a higher level of review, authority, or computational scrutiny.
Not one score
Escalation is not triggered by one universal confidence score. The decision can depend on:
- Uncertainty
- Financial consequence
- Customer consequence
- Permission
- Policy
- Repeated failures
The same technical uncertainty can produce different outcomes depending on what the system is about to do.
Consequence-aware routing
A low-confidence internal classification may be inexpensive to rerun or send to another model. A proposed customer-facing action with the same uncertainty may require human approval. A permission conflict can block execution regardless of model confidence.
- Continue
- Verify
- Human review
- Stop
This separates quality assessment from authority to act. A model may be correct enough to continue an investigation but not sufficiently reliable to authorize a consequential write.
Repeated failure
Escalation can also depend on execution history. One malformed output may justify a retry. Repeated malformed outputs may indicate a model, prompt, tool, or upstream-data failure and should move out of the normal retry loop.
Without an escalation ceiling, retries can conceal a persistent defect while consuming more compute and delaying the inevitable human review.
Preserve the investigation
Escalation should carry forward the system’s work. The next reviewer can receive the triggering condition, evidence, prior tool results, validation failures, uncertainty, and proposed action rather than starting from an empty ticket.
Escalation is supposed to preserve human authority — not recreate the manual workload the system was designed to remove.
Design objective
The correct escalation policy is workload-specific. Escalating too little increases the chance that uncertain systems take consequential actions. Escalating too much pushes routine work back to people.
Our objective is risk-adjusted escalation: routine work continues at machine speed, ambiguous cases receive additional scrutiny, and high-consequence decisions cross the appropriate authority boundary before execution.
Escalation policy is versioned
Escalation rules can change as the company changes its tolerance for risk, delegation, or customer impact. A threshold that is appropriate for an internal operating recommendation may be inappropriate once the same workflow is permitted to write into a production system. The escalation boundary therefore belongs to the deployed workflow configuration rather than being embedded informally in prompts.
For important workflows, the system can preserve which escalation policy was active when a decision was made. That gives us a clearer distinction between three failure classes: the model produced a bad result, the workflow failed to detect the risk, or the escalation policy itself was configured too permissively.
Those are different engineering problems and should remain distinguishable.