Threshold-Based Escalation Decision Prompt

This prompt is for platform engineers and AI reliability engineers who need a deterministic, auditable gate between autonomous AI action and human review. It takes a confidence score, the action the system wants to take, and a risk profile, then returns a binary decision: proceed or escalate. Use it inside agent harnesses, RAG pipelines, support triage systems, or any workflow where a model's uncertainty signal must trigger a hard boundary. This is not a prompt for generating confidence scores. It assumes you already have a confidence value from a classifier, model self-assessment, or upstream evaluation step. The prompt enforces the policy, not the measurement.

Deploy this prompt when you have a known confidence score from a reliable upstream source—such as a calibrated classifier output, a model's log probability, or a structured self-assessment—and you need to enforce a consistent, auditable escalation policy. It is ideal for high-stakes workflows where a wrong autonomous action carries significant cost: financial transactions, clinical documentation, legal filings, or safety-critical tool calls. The prompt works best when the risk profile and threshold are explicitly defined in your application logic and passed as variables, rather than relying on the model to infer them from vague instructions. Do not use this prompt when you need the model to estimate its own confidence from scratch, when the confidence score is derived from an unreliable heuristic, or when the action space is too ambiguous to define a clear proceed/escalate boundary.

Before wiring this into production, define your escalation path: what happens after the model returns escalate? The prompt's output should trigger a specific handler—a human review queue, a clarification loop, a safe fallback response, or a hard abort. Log every decision with the input confidence score, threshold, risk profile, and model rationale for auditability. Test the prompt against boundary cases where the confidence score equals the threshold exactly, and validate that the model's behavior matches your policy. If the upstream confidence source drifts or degrades, this prompt will faithfully enforce a broken threshold, so pair it with confidence calibration monitoring.

This prompt template acts as a deterministic decision gate for your application harness. It takes a structured input containing a confidence score, the action the system wants to take, and a risk profile, and returns a strict JSON decision with a rationale. The prompt is designed to be called after your primary workflow produces a confidence estimate, not as a standalone classifier. Use it to enforce consistent escalation behavior across different parts of your product without hard-coding brittle threshold rules in application code.

textCopy
You are a decision-gate classifier for an AI operations platform. Your only job is to decide whether to ESCALATE or PROCEED based on the provided confidence score, action context, and risk profile.

## INPUT
- Confidence Score: [CONFIDENCE_SCORE] (0.0 to 1.0)
- Action Context: [ACTION_CONTEXT]
- Risk Profile: [RISK_PROFILE]

## RISK PROFILES
- LOW: Routine, reversible actions (e.g., tagging, sorting, drafting). Escalate only if confidence < 0.65.
- MEDIUM: Important but recoverable actions (e.g., sending a notification, updating a record). Escalate if confidence < 0.80.
- HIGH: Critical or irreversible actions (e.g., sending an email, modifying a production config, financial transactions). Escalate if confidence < 0.92.

## DECISION RULES
1. Compare [CONFIDENCE_SCORE] against the threshold for [RISK_PROFILE].
2. If the score is below the threshold, the decision is ESCALATE.
3. If the score is at or above the threshold, the decision is PROCEED.
4. If the confidence score is exactly on a boundary, treat it as PROCEED but note the boundary condition in the rationale.
5. If [CONFIDENCE_SCORE] is not a valid number between 0.0 and 1.0, the decision is ESCALATE with rationale "Invalid confidence score."

## OUTPUT SCHEMA
Return ONLY a valid JSON object with no additional text, markdown fences, or commentary:
{
  "decision": "ESCALATE" | "PROCEED",
  "confidence_score": float,
  "threshold_applied": float,
  "risk_profile": "LOW" | "MEDIUM" | "HIGH",
  "rationale": "string explaining the decision with reference to the score and threshold"
}

## EXAMPLES
Input: Confidence Score: 0.72, Action Context: "Assign priority label to support ticket", Risk Profile: LOW
Output: {"decision": "PROCEED", "confidence_score": 0.72, "threshold_applied": 0.65, "risk_profile": "LOW", "rationale": "Score 0.72 meets LOW threshold of 0.65. Action is routine and reversible."}

Input: Confidence Score: 0.78, Action Context: "Send account deactivation confirmation email", Risk Profile: HIGH
Output: {"decision": "ESCALATE", "confidence_score": 0.78, "threshold_applied": 0.92, "risk_profile": "HIGH", "rationale": "Score 0.78 is below HIGH threshold of 0.92. Sending email is irreversible and requires human review."}

Input: Confidence Score: 0.80, Action Context: "Update customer phone number in CRM", Risk Profile: MEDIUM
Output: {"decision": "PROCEED", "confidence_score": 0.80, "threshold_applied": 0.80, "risk_profile": "MEDIUM", "rationale": "Score 0.80 meets MEDIUM threshold of 0.80 exactly. Boundary case, proceeding with standard logging."}

Adaptation notes: Replace the threshold values in the RISK PROFILES section with your organization's calibrated numbers. The examples are critical for teaching the model boundary-case behavior—keep at least one boundary example. If your system uses multiple confidence dimensions (e.g., intent confidence plus entity extraction confidence), combine them into a single [CONFIDENCE_SCORE] before calling this prompt, or extend the input schema to accept a confidence breakdown. The output schema is intentionally flat to make parsing reliable; do not nest the decision inside optional wrappers. Always validate the returned JSON against the schema before acting on the decision, and log every ESCALATE outcome with the full rationale for audit trails.

The Threshold-Based Escalation Decision Prompt is designed to be called as a synchronous decision gate inside an application pipeline, not as a standalone chat interaction. The prompt receives a structured input payload containing a confidence score, action context, and risk profile, and it must return a deterministic escalate or proceed decision with rationale. Because this prompt controls whether an automated action executes or a human is summoned, the harness must treat the model's output as advisory until validated against hard rules. The harness should enforce a fail-safe default: if the model response is missing, malformed, or times out, the system must escalate to human review rather than proceeding autonomously.

Wire the prompt into your application with a validation layer that parses the model's JSON output and checks the following before acting on the decision: (1) the decision field is present and exactly matches escalate or proceed; (2) the rationale field is a non-empty string; (3) if decision is proceed, the harness confirms that the input confidence score exceeds the minimum threshold defined in your risk profile, regardless of what the model returned. This last check is critical—the model can hallucinate a proceed decision even when the numeric score is below threshold. Implement a retry budget of up to 2 additional attempts if the output fails validation, using an exponential backoff starting at 500ms. On the third failure, log the raw response and escalate. For high-risk domains (healthcare, finance, safety-critical operations), add a human-in-the-loop review step even when the model returns proceed, by surfacing the decision and rationale in a review queue with a short timeout before execution.

Choose a model with strong JSON-mode support and low latency for this gate—GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Flash are suitable defaults. Avoid models with known instruction-following weaknesses under 7B parameters unless you've validated their schema adherence on your specific threshold boundary test cases. Log every decision with the full input payload, model response, validation result, and final action taken. This audit trail is essential for tuning thresholds, detecting drift, and defending decisions during incident review. Next, build the eval harness described in the Testing and Evaluation section to confirm your implementation handles boundary cases correctly before deploying to production.