Context Conflict Escalation Prompt Template

This prompt is designed for production assistant teams—copilots, support agents, and regulated assistants—that have exhausted all automated context conflict resolution strategies and still face a blocking conflict. A blocking conflict is one where the system cannot safely or correctly complete the task without violating user intent, system policy, or factual grounding. Before reaching for this escalation prompt, your system must have already attempted clarification, evidence re-ranking, instruction hierarchy enforcement, or a structured repair loop. The prompt's job is to produce a structured escalation summary that a human reviewer can act on immediately, not to attempt yet another automated fix.

The ideal user of this prompt is an AI engineer or product developer integrating it into a human-in-the-loop (HITL) review queue. Required context includes the full conflict history, a record of every automated resolution strategy attempted and its outcome, the conflicting context elements (e.g., session turn vs. retrieved document), and the task that is blocked. The prompt is not a general-purpose error handler. Do not use this prompt for first-occurrence ambiguities that a clarification question could resolve, for low-severity conflicts where a safe default answer is acceptable, or for conflicts that can be resolved by re-ranking evidence sources. Using it prematurely will flood your review queue with noise and erode reviewer trust.

Before wiring this into production, define clear escalation gates in your application logic. The prompt should only be invoked when a conflict severity score exceeds a defined threshold, when a repair loop counter hits its maximum retries, or when a safety-critical policy violation is possible. The output of this prompt should be logged as part of your audit trail and routed to a review interface, not exposed directly to end users. The next section provides the copy-ready prompt template you will adapt to your specific conflict taxonomy and review workflow.

This template is designed to be the final step in a context conflict resolution pipeline. It should be invoked only after automated repair, clarification, and resolution strategies have been exhausted. The prompt instructs the model to synthesize the conflict history, document the attempted resolutions, and produce a clear, actionable summary for a human reviewer. The output is a structured escalation payload, not a conversational message to the end-user.

textCopy
You are an escalation specialist for an AI assistant system. Your task is to produce a structured summary for a human reviewer when a context conflict cannot be resolved automatically. Do not attempt to resolve the conflict. Your goal is to provide a clear, concise, and complete report that enables a human to make a quick, informed decision.

## Conflict History
A chronological list of user inputs, system actions, and tool outputs that led to the conflict.
[CONFLICT_HISTORY]

## Conflicting Elements
A precise description of the two or more pieces of context that are in conflict. Cite specific sources (e.g., "User message at Turn 3," "Retrieved Document A, Paragraph 2," "System Policy: Data Retention").
[CONFLICTING_ELEMENTS]

## Attempted Resolutions
A list of automated strategies that were attempted and why they failed. Examples include: "Clarification question asked but user response was ambiguous," "Evidence re-ranking did not resolve contradiction," "Priority shift confirmation was denied."
[ATTEMPTED_RESOLUTIONS]

## Risk Level
[RISK_LEVEL]

## Output Schema
Generate a JSON object with the following fields. Do not include any other text.
{
  "escalation_id": "string, a unique identifier for this conflict instance",
  "summary": "string, a one-sentence summary of the conflict for a busy reviewer",
  "conflict_type": "string, classified as one of: 'user_contradiction', 'session_vs_retrieval', 'session_vs_policy', 'tool_output_mismatch', 'instruction_hierarchy_violation', 'other'",
  "blocking_issue": "string, a clear explanation of what is preventing the assistant from proceeding",
  "recommended_human_action": "string, a specific, actionable recommendation for the reviewer (e.g., 'Override policy X for this session,' 'Confirm which user instruction to follow,' 'Manually correct the tool output')",
  "context_for_reviewer": "string, a concise but complete summary of the relevant history and conflicting elements, written for a human",
  "risk_justification": "string, an explanation of why the assigned risk level is appropriate"
}

## Constraints
- Do not fabricate information. Base the report strictly on the provided [CONFLICT_HISTORY], [CONFLICTING_ELEMENTS], and [ATTEMPTED_RESOLUTIONS].
- If the provided information is insufficient to complete the report, set the 'blocking_issue' to 'INSUFFICIENT_DATA_FOR_ESCALATION' and explain what is missing in the 'context_for_reviewer' field.
- The 'recommended_human_action' must be a concrete next step, not a vague statement like "review the issue."
- If the [RISK_LEVEL] is 'safety_critical', the 'summary' must begin with the prefix 'SAFETY-CRITICAL: '.

To adapt this template, replace the square-bracket placeholders with data from your application's state manager. The [CONFLICT_HISTORY] should be a serialized timeline of relevant turns, not the entire raw session log. The [ATTEMPTED_RESOLUTIONS] placeholder is critical for preventing the human reviewer from repeating failed automated steps. Before routing the model's output to a review queue, validate the JSON against the schema and check that the conflict_type matches one of the enumerated values. If the blocking_issue field contains the INSUFFICIENT_DATA_FOR_ESCALATION signal, route the payload to a debugging queue instead of a human reviewer, as this indicates a failure in the upstream data assembly process.

The Context Conflict Escalation Prompt is not a standalone module; it is a decision point in a larger orchestration loop. Wire it into your application after a conflict detection step has already identified an unresolvable contradiction between user instructions, session state, system policy, or retrieved evidence. The escalation prompt should only fire when automated resolution strategies—such as the Contradictory Instruction Resolution Prompt or the Context vs Retrieved Evidence Conflict Prompt—have failed or returned a low-confidence result. This prevents premature escalation on conflicts that the system can resolve autonomously.

Implement a guard layer before calling this prompt. Check that the conflict has persisted across at least one repair attempt, that the severity score meets your escalation threshold (e.g., severity >= 4 on a 1–5 scale), and that the conflict type is in your escalation allowlist. Safety-critical conflicts—such as policy violations, medical contradictions, or financial instruction conflicts—should bypass the retry limit and escalate immediately. Pass the full conflict history, attempted resolutions, and relevant context into the prompt's [CONFLICT_HISTORY], [RESOLUTION_ATTEMPTS], and [CONTEXT] placeholders. The [RISK_LEVEL] placeholder should be set to high, medium, or low based on your application's risk taxonomy, which controls the urgency language in the escalation summary.

After the model returns the structured escalation summary, validate the output against your expected schema before routing it to a human review queue. Check that required fields—conflict_summary, attempted_resolutions, recommended_human_action, and escalation_reason—are present and non-empty. If the model fails to produce valid JSON after two retries using your Output Repair and Validation Prompt, log the raw output and flag it for manual triage. Never silently drop a failed escalation; a missing escalation on a safety-critical conflict is a higher-risk failure than a false positive.

Log every escalation event with the full prompt payload, model response, validation result, and routing decision. Include a unique conflict_id and session_id so your audit trail connects the escalation to the original conversation. For regulated domains, store the escalation summary in an append-only log and require a human reviewer to acknowledge receipt before the session can continue. Use a dead-letter queue pattern: if the human review system is unavailable, the escalation should be persisted and retried with backoff, not discarded.

Choose your model based on the risk level. For low-risk conflicts, a fast model like GPT-4o-mini or Claude Haiku is sufficient. For high-risk or safety-critical escalations, use a more capable model like GPT-4o or Claude Sonnet, and consider running a second verification pass with an LLM Judge prompt that checks whether the escalation summary accurately reflects the conflict history. Do not use this prompt with models that have known instruction-following weaknesses on structured output tasks without additional post-processing.

Avoid wiring this prompt directly to an end-user-facing message. The escalation summary is an internal artifact for human reviewers, not a user communication. If you need to inform the user that escalation is occurring, use a separate, user-facing message template that does not expose internal conflict details, resolution attempts, or system policy language. This separation prevents information leakage and keeps the escalation payload clean for the review team.