Policy Conflict Escalation Decision Prompt

This prompt is the decision gate for human-in-the-loop systems that encounter ambiguous or high-risk collisions between system instructions, user requests, tool outputs, or policy constraints. Its job is not to resolve the conflict but to produce a structured escalation decision—complete with a confidence score, risk factors, and a recommended review queue—so that an automated pipeline can reliably hand off work to a human reviewer. The ideal user is an AI platform engineer or product safety engineer building a production system where silent auto-resolution of every directive collision is unacceptable. Required context includes the conflicting directives themselves, the surrounding conversation or tool-call trace, the active policy stack, and any prior escalation history for the same session or user.

Use this prompt when your application has a defined set of behavioral policies and tool-use rules, but you cannot safely automate every edge case. For example, a customer-support assistant might have a policy to never disclose internal pricing logic, but a user's legitimate request for a refund calculation could trigger a tool that returns raw cost data. The prompt should receive both the system policy ('never disclose internal pricing logic') and the tool output, then decide whether the conflict is safe to auto-resolve or requires escalation to a billing specialist. The prompt expects a structured output—typically JSON—with fields for escalation_decision (boolean), confidence_score (0.0–1.0), risk_factors (array of strings), recommended_queue (string), and rationale (string). This structure lets the application route the case, log the decision, and notify the right team without manual triage.

Do not use this prompt for conflicts that are already covered by explicit, tested precedence rules in your system prompt. If your instruction hierarchy clearly states that system policies always override user requests, and you have regression tests proving that behavior, then auto-resolution is the correct path—adding an escalation layer here would only add latency and false positives. Similarly, do not use this prompt for low-risk conflicts where the cost of a wrong decision is negligible; the escalation overhead should be reserved for cases involving financial liability, privacy exposure, safety violations, or regulatory non-compliance. Before wiring this into production, calibrate the confidence threshold against a labeled dataset of known escalation cases to balance false-positive and false-negative rates. The next step after reading this section is to review the prompt template and implementation harness to understand how to integrate this decision layer into your existing orchestration code.

This template is the core inference call for a human-in-the-loop escalation system. It accepts a structured description of conflicting directives, the operational context, and your organization's risk tolerance. The model's job is to produce a machine-readable escalation decision, not to resolve the conflict itself. Populate the square-bracket placeholders with data from your policy engine, runtime monitors, or upstream classifiers before sending the request to the model. The output is designed to be parsed by an orchestration layer that either proceeds autonomously or routes to a review queue.

textCopy
You are a policy conflict escalation classifier. Your task is to decide whether a detected conflict between two or more active instructions requires immediate human review. You do not resolve the conflict. You assess severity, risk, and confidence, then output a structured escalation decision.

[CONSTRAINTS]
- If any involved instruction is tagged as [HIGH_RISK_CATEGORIES], escalate unless confidence exceeds [AUTO_RESOLVE_CONFIDENCE_THRESHOLD].
- If the conflict involves user safety, regulated data, or financial liability, escalate regardless of confidence.
- If the model's own confidence in the correct precedence is below [MIN_CONFIDENCE_THRESHOLD], escalate.
- Do not fabricate resolution steps. Only classify and route.

[INPUT]
- Detected Conflict: [CONFLICT_DESCRIPTION]
- Involved Directives:
  1. [DIRECTIVE_A_SOURCE]: [DIRECTIVE_A_TEXT]
  2. [DIRECTIVE_B_SOURCE]: [DIRECTIVE_B_TEXT]
- Active Priority Stack (highest to lowest): [PRIORITY_STACK]
- User-Facing Impact: [USER_IMPACT_DESCRIPTION]
- Current Session Context: [SESSION_CONTEXT_SUMMARY]

[OUTPUT_SCHEMA]
Return valid JSON only:
{
  "decision": "ESCALATE" | "AUTO_RESOLVE",
  "confidence": 0.0-1.0,
  "risk_level": "LOW" | "MEDIUM" | "HIGH" | "CRITICAL",
  "primary_risk_factor": "string",
  "recommended_queue": "string | null",
  "auto_resolution_rationale": "string | null",
  "escalation_reason": "string | null"
}

[EXAMPLES]
Example 1:
Input: Conflict between user request to export all customer PII and system policy prohibiting bulk PII export. Priority stack places system policy above user request.
Output: {"decision": "ESCALATE", "confidence": 0.98, "risk_level": "CRITICAL", "primary_risk_factor": "regulated_data_exposure", "recommended_queue": "compliance_review", "auto_resolution_rationale": null, "escalation_reason": "Conflict involves regulated PII export regardless of priority clarity."}

Example 2:
Input: Conflict between two tool outputs with minor formatting disagreement. Priority stack is clear. No user-facing safety impact.
Output: {"decision": "AUTO_RESOLVE", "confidence": 0.94, "risk_level": "LOW", "primary_risk_factor": "none", "recommended_queue": null, "auto_resolution_rationale": "Formatting-only conflict with clear precedence and no safety impact.", "escalation_reason": null}

[TOOLS]
You have access to the following context retrieval function if needed:
- get_policy_details(policy_id: string) -> {text: string, risk_category: string, last_updated: string}
Call this only if the directive text provided in [INPUT] is insufficient to assess risk.

[RULES]
- Do not hallucinate policy content. Use only provided directive text or retrieved policy details.
- If risk_level is CRITICAL or HIGH, decision must be ESCALATE.
- If confidence is below [MIN_CONFIDENCE_THRESHOLD], decision must be ESCALATE.

Adapt this template by adjusting the placeholders to match your operational taxonomy. Replace [HIGH_RISK_CATEGORIES] with your organization's actual risk labels (e.g., 'PII_export', 'financial_transaction_modification', 'safety_policy_override'). Set [AUTO_RESOLVE_CONFIDENCE_THRESHOLD] and [MIN_CONFIDENCE_THRESHOLD] based on your risk appetite—start conservative at 0.95 and 0.80 respectively, then tune using the false-positive and false-negative metrics from your eval harness. The [PRIORITY_STACK] should be populated from your system's runtime instruction precedence resolver, not hardcoded. If your application does not use tool-calling, remove the [TOOLS] block to avoid confusing the model with an unavailable capability.

Before deploying, validate that your orchestration layer can parse the JSON output and route to the correct queue. Build a retry wrapper that handles malformed JSON by re-prompting with the same input and a brief format reminder. Log every escalation decision with the full input context for auditability. In high-stakes domains, consider adding a second-pass verification step where a different model or a human spot-checks a sample of AUTO_RESOLVE decisions to catch overconfident misclassifications. The primary failure mode is false negatives—conflicts that should have been escalated but were auto-resolved—so bias your thresholds toward escalation until you have production data.

This prompt is not a conversational reply; it is a decision gate. Call it after your conflict detection logic identifies a collision that the priority stack cannot resolve cleanly. The model's output must be parsed as structured JSON and validated before any escalation action is taken. Log every decision with the full prompt context and model response for auditability. If the output fails JSON validation, retry once with a stricter schema instruction. If it fails again, default to the safest escalation queue and log the failure.

To measure reliability, compare the model's decision against a human-labeled dataset of known conflicts. A false positive is an unnecessary escalation that wastes reviewer time; a false negative is a missed escalation that led to a policy violation. Track both rates over time and set thresholds for alerting. For model choice, prefer a model with strong instruction-following and structured output capabilities. Set temperature=0 to reduce variance in decision thresholds. If your application requires explainability, include a justification field in the output schema and store it alongside the decision for downstream review.

Wire the prompt into a decision function that accepts the conflicting directives, the user context, and the risk level as inputs. Validate the JSON response against a strict schema that includes escalation_decision (boolean), confidence (0-1 float), review_queue (enum), and risk_factors (array of strings). If confidence falls below your operational threshold, route to human review regardless of the boolean decision. Never silently accept an unvalidated model output as an escalation action. Log the raw prompt, the parsed decision, the validation result, and the final routing action in a structured format that your observability stack can query.