Conflict Resolution Decision Prompt for AI Assistants

This prompt is a decision engine for conversational AI teams building research assistants and decision-support systems. Its job is to sit between evidence retrieval and answer generation, deciding how to handle situations where retrieved sources disagree on a factual claim. The core workflow is straightforward: the prompt takes a user question, a set of conflicting evidence passages, and a resolution policy, then outputs a structured decision—present both sides, defer to a higher-authority source, express calibrated uncertainty, or refuse to answer. This is not a prompt for generating user-facing text; it is a control-plane prompt that produces a machine-readable instruction for the next stage of your pipeline.

You should use this prompt when your RAG pipeline's contradiction detection step has flagged a conflict and you need a consistent, auditable resolution strategy before the model speaks to the user. The required inputs are: a user question, a set of evidence passages with source metadata (authority level, recency, and a unique identifier), and a resolution policy that defines your organization's rules for handling disputes. The output is a structured JSON decision with a strategy field (one of present_both_sides, defer_to_authority, express_uncertainty, or refuse_to_answer), a reasoning field explaining the choice, and an action field specifying which sources to use and how to frame the response. This structure ensures every conflict is handled with the same logic, making your system's behavior auditable and debuggable.

Do not use this prompt when evidence is unanimous, when the conflict is purely interpretive with no factual disagreement, or when the system lacks source metadata needed for authority assessment. It is also the wrong tool when the user's question is ambiguous and the real problem is query understanding rather than evidence conflict. In high-stakes domains such as healthcare, legal, or financial advice, the refuse_to_answer strategy should be the default unless a human reviewer has approved the resolution policy. The next step after implementing this prompt is to build an evaluation harness that tests each resolution strategy against known conflict scenarios, measuring whether the prompt consistently applies your policy and correctly identifies when escalation is required.

This template is designed to be pasted directly into your system prompt or message template. It instructs the model to analyze a set of conflicting evidence passages and select a resolution strategy: present both sides, defer to a higher-authority source, express calibrated uncertainty, or refuse to answer. The prompt uses square-bracket placeholders that your application must populate at runtime from your conflict detection pipeline, evidence store, and policy configuration.

textCopy
You are a conflict resolution decision engine for an AI research assistant. Your task is to decide how to present conflicting evidence to a user.

## INPUT
User Question: [USER_QUESTION]

Conflicting Evidence Set:
[CONFLICTING_EVIDENCE_PAIRS]
- Each pair includes Claim A, Source A, Claim B, Source B, and a Conflict Type.

Source Reliability Scores:
[SOURCE_RELIABILITY_MAP]
- A mapping of source identifiers to reliability scores (0.0-1.0) and recency timestamps.

## POLICY CONSTRAINTS
[POLICY_CONSTRAINTS]
- Rules that govern resolution behavior, such as: "Never present claims from sources with reliability < 0.4," "For medical questions, always express uncertainty and recommend professional consultation," or "If sources disagree and the highest-reliability source is above 0.8, defer to it."

## RESOLUTION STRATEGIES
Choose exactly one strategy per conflict:
- **present_both**: Both claims are from sufficiently reliable sources; present them with attribution and note the disagreement.
- **defer_to_authority**: One source is significantly more reliable; present the higher-authority claim and note that a less reliable source disagrees.
- **express_uncertainty**: Sources are equally reliable but conflict; explain what is known, what is disputed, and the level of confidence.
- **refuse_to_answer**: No source meets the minimum reliability threshold or the topic is disallowed by policy; refuse and explain why.

## ESCALATION CRITERIA
[ESCALATION_CRITERIA]
- Conditions that require flagging for human review, such as: "Conflict severity is 'high' and involves a regulated domain," or "User question implies a high-stakes decision."

## OUTPUT SCHEMA
Return a valid JSON object with this structure:
{
  "decisions": [
    {
      "conflict_id": "string",
      "strategy": "present_both | defer_to_authority | express_uncertainty | refuse_to_answer",
      "rationale": "string explaining the decision with reference to policy and source scores",
      "presentation_plan": {
        "primary_claim": "string or null",
        "primary_source": "string or null",
        "conflicting_claim": "string or null",
        "conflicting_source": "string or null",
        "uncertainty_statement": "string or null",
        "refusal_reason": "string or null"
      },
      "escalate_for_review": true or false,
      "escalation_reason": "string or null"
    }
  ],
  "global_escalation": true or false,
  "global_notes": "string or null"
}

## CONSTRAINTS
- Do not fabricate source content or reliability scores.
- If policy requires human review, set escalate_for_review to true regardless of strategy.
- For medical, legal, or financial topics, prefer express_uncertainty or refuse_to_answer unless policy explicitly allows otherwise.
- If no conflict is actually present in the evidence, return an empty decisions array and note this in global_notes.

To adapt this template, replace each bracketed placeholder with live data from your pipeline. [CONFLICTING_EVIDENCE_PAIRS] should be a structured list of detected contradictions, each with source identifiers that map to entries in [SOURCE_RELIABILITY_MAP]. [POLICY_CONSTRAINTS] and [ESCALATION_CRITERIA] should be drawn from your application's configuration layer, not hardcoded into the prompt. After the model returns its decision, validate the JSON schema before routing to your answer synthesis or human review queue. For high-stakes domains, always log the full decision payload and source inputs for auditability.

This prompt is a decision router, not a content generator. It should be placed after an evidence conflict detection step and before any user-facing answer synthesis. The application layer must supply the detected conflict summary, the user's original question, and the relevant source metadata. The prompt's output is a structured decision object that downstream code uses to branch: present both sides, defer to a higher-authority source, express uncertainty, or refuse to answer. Do not pass the raw prompt output directly to the user; the application must interpret the decision and execute the corresponding resolution path.

Wire the prompt into a decision-service function that accepts a conflict_payload containing the conflicting claims, source identifiers, and authority scores. Validate the model's output against a strict schema requiring a resolution_strategy enum (present_both, defer_to_authority, express_uncertainty, refuse_to_answer), a rationale string, and an optional deferred_source_id. If the output fails schema validation, retry once with the validation error appended to the prompt as a correction hint. If the retry also fails, default to express_uncertainty and log the failure for review. For high-stakes domains, route defer_to_authority and refuse_to_answer decisions to a human review queue before the resolution is executed. Log every decision with the input conflict summary, the model's chosen strategy, the rationale, and the final executed path to create an audit trail for governance reviews.

Model choice matters here. Use a model with strong instruction-following and low refusal-avoidance bias; models that over-prioritize helpfulness may force a present_both strategy when refuse_to_answer is the correct safety decision. Set temperature to 0 to maximize decision consistency. If your application uses retrieval-augmented generation, ensure the conflict detection step runs on the raw retrieved passages before any synthesis, and pass only the detected conflict pairs into this prompt—not the full retrieval set. Avoid the temptation to combine conflict detection and resolution into a single prompt; separating them improves debuggability and lets you tune each step independently. The next step after a successful resolution decision is to route to the appropriate answer-generation or escalation handler based on the chosen strategy.