Context Conflict Detection Between Turns Prompt

This prompt is for copilot and agent builders who need to detect when a user's new input contradicts a constraint, preference, or fact established earlier in the conversation. The job-to-be-done is not just spotting a contradiction, but producing a structured conflict report that surfaces the specific conflicting statements and generates a neutral, non-accusatory resolution question. The ideal user is an AI engineer integrating this into a multi-turn dialogue system where the assistant must maintain state integrity across turns—think of a travel booking copilot where the user first says 'no flights before 9 AM' and later asks for 'the earliest option,' or a configuration assistant where a previously set budget cap is violated by a new request.

Use this prompt when your application maintains a persistent set of user-provided constraints, preferences, or facts across conversation turns and you need to catch contradictions before acting on them. It is particularly valuable in task-oriented assistants, configuration wizards, and any copilot where the cost of silently violating a prior constraint is high—such as making a purchase, sending a communication, or generating a final deliverable. The prompt expects two inputs: a structured representation of prior constraints or facts from the session state, and the new user turn. It returns a conflict assessment with a severity flag, the exact conflicting statements, and a resolution question that gives the user a clear choice without implying they made a mistake.

Do not use this prompt when the prior context is purely informational rather than constraining, when the user is explicitly overriding a previous instruction, or when the contradiction is trivial and the cost of interruption exceeds the cost of proceeding. It is also a poor fit for open-ended chat where there is no structured state to validate against. In high-stakes domains like healthcare or finance, this prompt is a detection layer, not a decision engine—always route confirmed conflicts to a human review step before taking action. For best results, pair this prompt with a session state tracker that maintains a machine-readable log of user-provided constraints, and run conflict detection before any tool call or final output that depends on those constraints.

This template is the core instruction set for a context conflict detection module. It is designed to be inserted into a system prompt or a dedicated analysis step before the main assistant generates a response. The prompt instructs the model to compare the latest user turn against a structured list of previously established constraints, preferences, or facts from the session. Its primary output is not a final answer to the user, but a diagnostic report that your application can use to decide whether to flag a conflict, ask a clarifying question, or proceed with an assumption.

textCopy
You are a context conflict detection module. Your task is to compare the user's latest input against a list of previously established constraints, preferences, and facts from the current session. You must identify any direct contradictions where the new input is incompatible with the prior context.

# PRIOR CONTEXT
A structured list of active constraints and facts from earlier in the session:
[PRIOR_CONTEXT]

# LATEST USER INPUT
The user's most recent message:
[USER_INPUT]

# INSTRUCTIONS
1. Analyze the [USER_INPUT] against each item in [PRIOR_CONTEXT].
2. Identify only direct, logical contradictions. Do not flag changes of topic, refinements, or new information that adds to prior context without negating it.
3. For each contradiction found, extract the two conflicting statements: one from [PRIOR_CONTEXT] and one from [USER_INPUT].
4. Formulate a single, neutral resolution question that surfaces the contradiction without accusatory language. The question should ask the user to clarify which statement should take precedence.
5. If no contradictions are found, explicitly state that no conflicts were detected.

# OUTPUT SCHEMA
You must respond with a valid JSON object conforming to this schema:
{
  "conflicts_detected": boolean,
  "conflicts": [
    {
      "prior_statement": string,
      "conflicting_input": string,
      "resolution_question": string
    }
  ]
}

# CONSTRAINTS
- Do not fabricate conflicts. Only flag clear incompatibilities.
- The "resolution_question" must be a single, concise question.
- Maintain a neutral, helpful tone. Do not imply the user made a mistake.
- If [PRIOR_CONTEXT] is empty, set "conflicts_detected" to false.

To adapt this template for your application, you must define the structure of the [PRIOR_CONTEXT] placeholder. This should not be raw conversation history. Instead, it should be a pre-processed, structured list of active constraints extracted by a separate session state management module. For example, it could be a JSON array of strings like "User's budget is $500" or "Target audience is enterprise CTOs". The quality of this input is the single biggest factor in the prompt's success. Before deploying, run this prompt against a golden dataset of 50-100 turn pairs with known contradictions and non-contradictions to tune your [PRIOR_CONTEXT] extraction logic and set a confidence threshold for the conflicts_detected flag. In high-stakes applications, always route detected conflicts to a human reviewer for the final resolution question before it is shown to the user.

The Context Conflict Detection prompt is not a standalone chatbot; it is a state-inspection module that should be called before the assistant generates a response to a new user turn. In a production harness, this prompt sits between the dialogue state manager and the response generation step. When a new user message arrives, the harness retrieves the active session constraints, preferences, and prior decisions from the state store, packages them into the [PRIOR_CONTEXT] variable, and passes the raw [USER_INPUT] alongside it. The model returns a structured conflict report—either conflict_detected: false or a detailed conflict object with statement_a, statement_b, and a resolution_question. The harness must then branch: if no conflict is found, the main generation prompt proceeds normally; if a conflict is detected, the harness should pause response generation and surface the resolution question to the user before continuing. This prevents the assistant from silently choosing one constraint over another or generating output that violates previously stated user intent.

The output of this prompt must pass through a strict JSON schema validator before the harness acts on it. The expected schema includes a boolean conflict_detected field, and when true, a conflicts array where each object contains statement_a (the earlier constraint), statement_b (the contradictory new input), source_turn (an identifier for the prior turn), and resolution_question (a single, non-accusatory question). If the model output fails JSON parsing or schema validation, the harness should retry once with a repair prompt that includes the raw output and the schema error. After a second failure, log the raw output and escalate to a human reviewer rather than silently proceeding. For high-stakes domains such as healthcare or finance, even a successfully parsed conflict report should be logged to an audit trail with the session ID, turn numbers, and the resolution question shown to the user. This creates a reviewable record of when the system detected a contradiction and how it was resolved.

Model choice matters for this prompt. The task requires precise comparison of semantic intent across turns, not just keyword overlap. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller or older models that may conflate benign topic shifts with true conflicts, producing false-positive flags that annoy users with unnecessary clarification questions. To reduce false positives, include a [CONFIDENCE_THRESHOLD] parameter in the prompt template (e.g., 0.8) and instruct the model to only flag conflicts where the contradiction is clear, not where the user is simply adding new information or refining a preference. In your eval suite, maintain a golden dataset of turn pairs labeled as conflict, refinement, topic_shift, and new_information. Measure precision and recall on the conflict class specifically, and set a minimum precision bar (e.g., 0.85) before deploying a prompt variant. If false-positive rates exceed your threshold, tune the confidence parameter or add few-shot examples of refinements that should not be flagged as conflicts.

When a conflict is detected, the harness must not generate a full assistant response. Instead, it should surface only the resolution_question to the user, prefixed by a brief, neutral framing such as 'I want to make sure I follow your latest preference.' The user's answer to this question should then update the session state—either replacing the prior constraint or confirming that both constraints apply in different contexts—before the main generation prompt runs. Do not feed the conflict report itself into the main generation prompt; it contains meta-commentary about the contradiction that will confuse the response model. Only pass the resolved constraint set. Finally, instrument the harness to track the rate of conflict detection, the rate of user confirmation after a resolution question, and the rate of user corrections in subsequent turns. A rising correction rate after conflict resolution suggests the prompt is asking the wrong question or framing the contradiction poorly, and the resolution question language should be reviewed.