Context Conflict Resolution Audit Prompt

This prompt is for copilot and agent builders who need to audit how their AI system resolved contradictory information during a conversation. The core job-to-be-done is producing a structured, reviewable record whenever a user's input conflicts with previously retrieved evidence, established system instructions, or prior user statements. This is not a prompt for resolving conflicts in real-time; it is a post-turn or offline audit tool designed to make resolution logic transparent for debugging, compliance, and quality assurance workflows.

The ideal user is an AI engineer, QA lead, or compliance officer investigating a specific turn where the assistant's output seemed to violate a known constraint. You should use this prompt when you have a logged conversation, a flagged turn, and you need to answer: 'Why did the system choose this response over another?' The prompt requires the full context of the conflicting turn, including the user's input, the active system instructions, the retrieved evidence, and the assistant's final output. It is not suitable for real-time conflict resolution, for sessions without detailed logs, or for conflicts that are purely stylistic rather than factual or policy-based.

Do not use this prompt when you need a simple explanation of an assistant's reasoning, as it is specifically designed to isolate and trace the conflict resolution step. It is also inappropriate for auditing conflicts that arise from ambiguous user intent without a clear contradiction in evidence or policy. Before using this prompt, ensure you have already identified a specific turn where a conflict is suspected; this is a diagnostic tool, not a discovery tool. The output is a structured JSON record meant for logging systems, eval pipelines, or human review queues, not for direct display to end users.

This template is the core instruction set you'll send to the model. It is designed to be wrapped in your application's harness, where you inject the specific turn data, system policies, and output schema. The prompt instructs the model to act as an auditor, not the original assistant, forcing it to analyze the provided context for conflicts and document the resolution logic.

textCopy
You are a Conversation State Auditor. Your task is to analyze a single conversation turn where a user's input may have conflicted with previously retrieved evidence, established facts, or active system instructions. You must produce a structured audit record of how the conflict was resolved.

## INPUT DATA

**CURRENT USER INPUT:**
[USER_INPUT]

**PRIOR CONTEXT (Active Facts & Instructions):**
[PRIOR_CONTEXT]

**RETRIEVED EVIDENCE FOR THIS TURN:**
[RETRIEVED_EVIDENCE]

**ASSISTANT'S ACTUAL RESPONSE:**
[ASSISTANT_RESPONSE]

## AUDIT INSTRUCTIONS

1.  **Identify Conflict:** Determine if the [USER_INPUT] contradicts any information in the [PRIOR_CONTEXT] or [RETRIEVED_EVIDENCE]. If no conflict exists, state that explicitly and stop.
2.  **Analyze Resolution:** If a conflict exists, analyze the [ASSISTANT_RESPONSE] to determine which information source was prioritized: the user's new input, the prior context, or the retrieved evidence.
3.  **Identify Priority Rule:** Infer the priority rule that was applied (e.g., "User Input Overrides Stale Evidence," "System Policy Overrides User Request," "Newer Evidence Overrides Prior Context").
4.  **Identify Overridden Information:** Specify the exact piece of information that was overridden or discarded.
5.  **Produce Output:** Generate a JSON object strictly conforming to the [OUTPUT_SCHEMA].

## CONSTRAINTS

- Do not invent conflicts. Only report contradictions that are explicitly present in the provided text.
- If the resolution is ambiguous, set the `resolution_confidence` to "low" and explain the ambiguity in the `auditor_notes`.
- Cite the source of overridden information precisely.
- If the assistant's response ignored the conflict, flag this as a "MISSED_CONFLICT" in the `resolution_status` field.

## OUTPUT SCHEMA

You must output a single JSON object with the following structure:
{
  "conflict_detected": boolean,
  "conflict_summary": string | null, // A one-sentence description of the conflict, if any.
  "conflicting_sources": [string, string] | null, // The two sources in conflict (e.g., "user_input", "prior_context").
  "resolution_status": "RESOLVED" | "MISSED_CONFLICT" | "NO_CONFLICT",
  "priority_rule_applied": string | null, // e.g., "User Input Overrides Stale Evidence"
  "overridden_information": string | null, // The exact text that was discarded.
  "resolution_confidence": "high" | "medium" | "low",
  "auditor_notes": string // Explanation of the analysis, especially for ambiguous cases.
}

To adapt this template, replace the bracketed placeholders with your application's data. [PRIOR_CONTEXT] should be a structured summary of the session state, not the raw transcript. [RETRIEVED_EVIDENCE] should be the specific text chunks provided to the assistant for that turn. The [OUTPUT_SCHEMA] can be extended with fields like turn_id or timestamp, but the core logic should remain focused on the conflict resolution trace. For high-stakes compliance workflows, always route outputs with resolution_confidence set to "low" or a resolution_status of "MISSED_CONFLICT" to a human review queue before the audit record is finalized.

This prompt is designed to operate as a post-turn audit step in a copilot or agent pipeline. After each user turn where the system detects a potential conflict between user input and retrieved evidence or prior instructions, the prompt is invoked to produce a structured conflict resolution record. The prompt expects a specific turn context, the conflicting information sources, and the resolution the system applied. It is not a real-time decision prompt—it audits a decision that has already been made, making it suitable for asynchronous processing, batch audit jobs, and compliance review queues.

Wire the prompt into your application as a synchronous post-processing hook after the primary assistant response is generated but before the response is logged or surfaced to the user. The application layer must first detect a potential conflict by comparing the user's input against active context (retrieved evidence, prior instructions, session policies). If a conflict is detected, assemble the prompt inputs: the user turn text, the conflicting context items with source identifiers, the resolution the system chose, and the priority rule that governed the choice. Call the model with temperature=0 and response_format set to the expected JSON schema. Validate the output immediately: check that all required fields are present, that conflict_id is unique, that resolution_rule_applied matches one of your defined priority rules, and that overridden_information is non-empty when a conflict was resolved by choosing one source over another. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS]. If the retry also fails, log the raw output and flag for human review.

For high-stakes domains (healthcare, legal, finance), route all conflict audit records with severity: "high" or confidence_below: 0.9 to a human review queue before the record is committed to the audit log. Store the final audit record alongside the conversation turn in your audit database, indexed by session_id, turn_id, and conflict_id. Use these records to generate compliance reports, track resolution-rule misapplication rates, and feed back into prompt improvement cycles. Avoid wiring this prompt directly into the user-facing response path—audit prompts should never add latency to the user experience. Instead, run them as a non-blocking side effect or in a post-session batch process if real-time audit is not required.

Model choice matters. Use a model with strong structured output adherence and low hallucination rates for audit tasks. GPT-4o and Claude 3.5 Sonnet are suitable defaults. Avoid smaller or older models that may invent conflict details or misattribute sources. If you are running this prompt at scale, consider caching the prompt prefix (system instructions and schema definition) to reduce cost and latency. Monitor production for unlogged conflicts by periodically running a separate detection prompt over full conversation histories and comparing detected conflicts against your audit log—this is your primary eval for recall. For precision, sample audit records weekly and have a domain expert verify that the resolution_rule_applied matches your actual priority policy and that overridden_information accurately captures what was discarded.