Context Conflict Detection Prompt Template

This prompt is designed for copilot and assistant builders who need to validate new user input against facts previously established within the same conversation session. The core job-to-be-done is to prevent an assistant from acting on contradictory information, which can corrupt downstream slot-filling, tool calls, or generated responses. The ideal user is an AI engineer integrating this prompt as a guardrail step in a stateful dialogue pipeline, where a structured session state (e.g., a JSON object of confirmed slots) is maintained externally and passed into the prompt as [SESSION_CONTEXT].

You should use this prompt when your system has already extracted and committed facts from prior turns and needs to check a new user utterance for contradictions before updating that state. For example, if a user first states their account ID is '12345' and later refers to 'account 67890', this prompt should flag the conflict with the specific conflicting spans and a reason. It is not a general fact-checking prompt for verifying claims against an external knowledge base; it operates strictly within the boundary of the current session's established facts. Do not use this prompt for real-time hallucination detection in the assistant's own output or for validating information against a static database—those are separate workflows.

Before implementing this prompt, you must have a reliable mechanism for extracting and storing session facts, as the prompt's utility is entirely dependent on the quality of the [SESSION_CONTEXT] provided. A common failure mode is feeding the prompt an empty or incomplete context, which will result in no conflicts being detected. To integrate this into an application, place this prompt as a synchronous validation step after user input is received but before the main agentic loop or response generation. If a conflict is detected, the system should not silently overwrite the old fact; instead, it should surface the conflict to the user for clarification or log it for human review, depending on the [RISK_LEVEL] defined in your harness.

This prompt template is designed to be copied directly into your application code or prompt management system. It instructs the model to act as a context conflict detector, comparing the latest user utterance against a structured set of previously established session facts. The model must identify contradictions, flag the specific conflicting spans, and classify the nature of the conflict. Replace every square-bracket placeholder with the actual values from your application's session state, user input, and output schema requirements before sending the request.

textCopy
You are a context conflict detection system. Your job is to compare the latest user input against a set of previously established session facts and identify any contradictions.

## PREVIOUSLY ESTABLISHED FACTS
[SESSION_FACTS]

## LATEST USER INPUT
[USER_INPUT]

## CONFLICT DETECTION RULES
1. A conflict exists when the new input directly contradicts a previously established fact, makes a previously established fact impossible, or asserts a value that is mutually exclusive with a prior fact.
2. Do not flag clarifications, refinements, or additional details as conflicts unless they logically negate a prior fact.
3. Do not flag changes of topic or new, unrelated information as conflicts.
4. If the user explicitly corrects a prior statement, flag it as a CORRECTION conflict type.
5. If the new input implies a contradiction without explicitly stating it, flag it as an IMPLIED conflict type.
6. If the new input directly states something that contradicts a prior fact, flag it as a DIRECT conflict type.

## OUTPUT FORMAT
Return a valid JSON object with this exact schema:
{
  "conflicts_detected": boolean,
  "conflicts": [
    {
      "conflict_type": "DIRECT" | "IMPLIED" | "CORRECTION",
      "prior_fact": "The exact prior fact from SESSION_FACTS that is contradicted",
      "conflicting_span": "The exact text from USER_INPUT that creates the contradiction",
      "explanation": "A concise explanation of why these two statements conflict",
      "severity": "HIGH" | "MEDIUM" | "LOW"
    }
  ],
  "unaffected_facts": ["List of prior facts that remain valid and uncontradicted"]
}

## CONSTRAINTS
- Only return the JSON object. No other text.
- If no conflicts are detected, return an empty conflicts array and set conflicts_detected to false.
- Set severity to HIGH if the conflict would cause a downstream action failure, MEDIUM if it creates ambiguity, LOW if it is a minor inconsistency.
- Do not hallucinate conflicts. Only flag contradictions that are logically supported by the text.
[ADDITIONAL_CONSTRAINTS]

To adapt this template for your application, start by populating [SESSION_FACTS] with a structured list of facts extracted from prior turns. These should be atomic, verifiable statements such as 'User account type is enterprise' or 'Preferred contact method is email.' The [USER_INPUT] placeholder receives the raw text of the latest user message. Use [ADDITIONAL_CONSTRAINTS] to inject domain-specific rules, such as ignoring conflicts on fields that users are expected to update frequently or adding a minimum confidence threshold. Before deploying, validate the output against your expected JSON schema and run the prompt against a labeled conflict dataset to measure precision and recall. For high-risk domains where a missed conflict could cause financial or safety harm, route HIGH-severity conflicts to a human reviewer before the system acts on the contradiction.

The Context Conflict Detection prompt is not a standalone utility—it is a guard module that sits between the user input ingestion layer and the downstream reasoning or response generation pipeline. In a typical copilot architecture, every new user turn passes through a conflict check against the current session state before the assistant acts on it. The harness must supply the prompt with a structured representation of the session's established facts (the [SESSION_FACTS] placeholder) and the raw [NEW_USER_INPUT]. The output is a structured conflict report that the application can use to decide whether to proceed, ask for clarification, or flag for human review.

Wire this prompt as a pre-processing step with a strict timeout and a lightweight model. Use a fast, cost-effective model (such as GPT-4o-mini, Claude Haiku, or Gemini Flash) because conflict detection is a classification task that does not require deep reasoning. The harness should enforce a JSON output schema with fields for conflict_detected (boolean), conflicts (array of objects with session_fact_span, user_input_span, conflict_type, and severity), and rationale (string). Implement a retry loop with up to two retries if the output fails JSON schema validation. If the model returns conflict_detected: true, route the turn to a clarification sub-flow rather than allowing the assistant to act on contradictory information. Log every conflict detection result—including false negatives discovered later—to build an evaluation dataset for ongoing prompt tuning.

For high-stakes domains such as healthcare, legal, or financial copilots, add a human review gate when severity is high or when the conflict involves regulated data. The harness should serialize the conflict report alongside the session state and user input into an audit record before any downstream action is taken. Avoid the common failure mode of treating conflict detection as a one-shot check: if the user later corrects a fact, the harness must update the session state and re-run conflict detection on any pending actions that depended on the now-corrected fact. The next step is to integrate the conflict report into your session state manager so that unresolved conflicts block state mutations until they are resolved.