Escalation Threshold Definition Prompt for Operators

This prompt is designed for platform operators, AI safety engineers, and compliance architects who need to codify the boundary between autonomous agent execution and mandatory human review. The primary job-to-be-done is translating an organization's qualitative risk appetite, cost constraints, data sensitivity classifications, and confidence requirements into a structured, machine-readable policy. You should use this prompt during the design phase of an agent deployment, specifically before connecting the agent to production databases, financial ledgers, customer-facing communication channels, or any infrastructure governed by regulatory controls. The ideal user brings a clear understanding of their internal risk taxonomy, existing change management processes, and the specific tool actions that carry irreversible consequences.

This is a design-time policy generation prompt, not a runtime approval gate. It requires you to provide concrete inputs: a list of tool actions with their potential blast radius, your organization's data classification schema, cost center budgets, and acceptable false-positive versus false-negative trade-offs for human review. For example, you might define that any database UPDATE or DELETE operation affecting more than [N] rows requires approval, or that any financial transaction exceeding [AMOUNT] in a [CURRENCY] outside of business hours must escalate. The prompt's output is a structured ruleset with tiered thresholds, calibration notes, and explicit documentation of the trade-offs you are making. This output then becomes the source of truth for your runtime guardrail system, ensuring consistent enforcement across all agent tool calls.

Do not use this prompt if you are looking for a one-size-fits-all solution or if your organization lacks defined risk and data sensitivity categories. The prompt's effectiveness is directly proportional to the specificity of the inputs you provide; vague inputs will produce a generic policy that is either too permissive or too restrictive for production use. Before using this prompt, ensure you have completed an inventory of your agent's tool permissions and have stakeholder alignment on the cost of a false positive (unnecessary human review slowing down a safe operation) versus a false negative (an agent autonomously executing a damaging action). Once you have generated the policy, your next step is to hard-code these rules into your agent's tool-execution middleware, not to rely on the agent's runtime judgment of the policy itself.

This prompt template is designed for platform operators who need to define, calibrate, and document the exact conditions under which an AI agent must escalate a proposed action for human approval instead of proceeding autonomously. The template accepts your organization's specific risk factors, scoring rubrics, and operational constraints as input and produces a structured set of threshold rules that can be directly implemented in an agent's tool-execution guardrails. Use this when moving from a general policy of 'escalate high-risk actions' to a precise, auditable, and testable specification.

textCopy
You are an escalation policy architect for an AI operations platform. Your task is to define precise, executable threshold rules that determine when an agent must escalate a proposed tool action for human approval.

## INPUT
- Action Proposal: [ACTION_DESCRIPTION]
- Tool Name: [TOOL_NAME]
- Affected Resources: [AFFECTED_RESOURCES]
- Context: [CONTEXT]

## RISK DIMENSIONS AND SCORING RUBRIC
Evaluate the proposed action against the following dimensions. Assign a score from 1 (Negligible) to 5 (Critical) for each.

1.  **Risk Score:** [RISK_SCORE_DEFINITION]
2.  **Cost Impact:** [COST_IMPACT_DEFINITION]
3.  **Blast Radius:** [BLAST_RADIUS_DEFINITION]
4.  **Data Sensitivity:** [DATA_SENSITIVITY_DEFINITION]
5.  **Confidence Level:** [CONFIDENCE_LEVEL_DEFINITION]

## THRESHOLD RULES
Determine the required action based on the following rules, evaluated in order:

- **Rule 1 (Hard Block):** If [HARD_BLOCK_CONDITION], the action is **BLOCKED** and must never proceed.
- **Rule 2 (Mandatory Escalation):** If [MANDATORY_ESCALATION_CONDITION], the action must **ESCALATE** for human approval.
- **Rule 3 (Conditional Auto-Approve):** If [CONDITIONAL_AUTO_APPROVE_CONDITION], the action can **AUTO-APPROVE** but must be logged for post-execution review.
- **Rule 4 (Default Auto-Approve):** If none of the above conditions are met, the action can **AUTO-APPROVE**.

## OUTPUT SCHEMA
Return a single JSON object conforming to this schema:
{
  "decision": "BLOCKED" | "ESCALATE" | "AUTO_APPROVE" | "AUTO_APPROVE_WITH_REVIEW",
  "triggered_rule": "string",
  "risk_assessment": {
    "risk_score": { "value": "number", "rationale": "string" },
    "cost_impact": { "value": "number", "rationale": "string" },
    "blast_radius": { "value": "number", "rationale": "string" },
    "data_sensitivity": { "value": "number", "rationale": "string" },
    "confidence_level": { "value": "number", "rationale": "string" }
  },
  "escalation_payload": {
    "summary": "A concise summary of the action and the reason for escalation, suitable for a human reviewer.",
    "rollback_plan": "A clear, step-by-step plan to reverse the action if approved and later found to be problematic.",
    "false_positive_risk": "An assessment of the likelihood that this escalation is a false positive (i.e., the action is actually safe).",
    "false_negative_risk": "An assessment of the potential impact if this action were incorrectly auto-approved."
  },
  "calibration_notes": "Notes on how the current thresholds performed against this input, including any suggestions for rule adjustment to reduce false positives/negatives."
}

## CONSTRAINTS
- Do not invent or assume any risk scores; derive them strictly from the provided definitions and the action proposal.
- If any required input is missing or ambiguous, set the decision to "ESCALATE" and note the missing information in the escalation summary.
- The rollback plan must be actionable and specific, not a generic statement.

To adapt this template, replace the square-bracket placeholders with your organization's specific definitions. The [RISK_SCORE_DEFINITION] and similar fields should contain clear, operationalized criteria. For example, a [COST_IMPACT_DEFINITION] might be: '1: < $10, 2: $10-$100, 3: $100-$1,000, 4: $1,000-$10,000, 5: > $10,000.' The [HARD_BLOCK_CONDITION] and other rule conditions should be expressed as logical statements referencing these scores, such as 'Data Sensitivity is 5 AND Blast Radius > 3.' After adapting the template, you must test it against a golden dataset of historical actions to calibrate the thresholds and tune the false-positive/false-negative trade-off before deploying it to production. This prompt is the first step in a workflow that should include validation of the output JSON, human review of the generated rules, and A/B testing against a shadow mode before enforcement.

This prompt is designed to be embedded in a platform administration interface where operators define and calibrate agent autonomy boundaries. The primary integration point is a threshold configuration workflow—an internal tool, CLI, or admin panel that collects operator inputs (risk tolerance, cost limits, blast radius constraints, data sensitivity levels) and feeds them into the prompt as structured variables. The prompt's output is a machine-readable threshold ruleset (JSON or YAML) that gets stored in a policy database and evaluated at runtime by the agent orchestration layer before every high-stakes tool call. Do not treat this as a one-time setup prompt; operators should re-run it when incident reviews reveal false positives (unnecessary escalations) or false negatives (missed escalations), feeding post-incident data back into the [CALIBRATION_FEEDBACK] variable.

Integration architecture: The prompt should sit behind a thin service that validates inputs before invocation and validates outputs before policy storage. Required pre-flight checks: confirm that [RISK_SCORE_WEIGHTS] sum to 1.0, that [COST_THRESHOLD_CURRENCY] matches the organization's billing currency, and that [BLAST_RADIUS_MAX] is a positive integer representing affected resources. After the model returns a threshold definition, run a schema validator that enforces: every threshold tier has a non-null escalation_action (one of auto_approve, human_review, block), every condition references a defined risk factor, and no tier has overlapping score ranges. If validation fails, surface the specific field errors to the operator rather than silently falling back to a default policy. For high-risk environments, add a human approval gate before the generated ruleset is promoted to production—an operator must explicitly sign off on the threshold table, with the prompt's output rendered as a diff against the currently active policy.

Model choice and retry strategy: Use a model with strong structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set response_format to json_object with the expected schema provided in [OUTPUT_SCHEMA]. If the model returns a malformed threshold definition, retry once with the validation errors injected into [CONSTRAINTS] as explicit correction instructions. If the second attempt also fails, escalate to the operator with the raw output and validation report—do not silently accept a broken policy. Logging and audit: Every threshold generation event should produce an immutable log entry containing: operator identity, input parameters, raw model output, validation result, and final policy state. This audit trail is essential for post-incident reviews where you need to trace why an agent escalated (or didn't) for a specific action. Store these logs in the same system that records agent tool execution decisions so correlation is straightforward during investigations.

Next steps after deployment: Once the threshold ruleset is live, monitor the ratio of auto-approved to escalated actions over the first week. If the escalation rate exceeds 40%, the thresholds are likely too conservative—re-run the prompt with adjusted [FALSE_POSITIVE_TOLERANCE] and [FALSE_NEGATIVE_TOLERANCE] values. If critical actions are auto-approved without review, the thresholds are too permissive—tighten [BLAST_RADIUS_MAX] and [DATA_SENSITIVITY_LEVEL] constraints. Avoid the common mistake of treating threshold configuration as a static artifact; it should be recalibrated quarterly or after any significant incident, with the prompt serving as the structured interface between operator intent and executable policy.