Conflicting Evidence Presentation Prompt for User-Facing Answers

This prompt is designed for customer-facing AI product teams who need to present conflicting evidence to end users in a way that is clear, neutral, and actionable. It formats disagreements from multiple sources without overwhelming the user, attributes each position to its source, and offers paths to explore each side. Use this prompt when your application surfaces answers from a retrieval-augmented generation (RAG) pipeline, a research assistant, or a decision-support tool where sources disagree. It is not a conflict detection prompt; it assumes conflicts have already been identified and passed in as structured input. The primary harness concern is maintaining strict neutrality while helping users assess the credibility and weight of each position.

The prompt requires a pre-processed input containing the user's original question and a structured list of conflicting positions, each with its source citation and a brief summary of the evidence. Do not use this prompt when conflicts are implicit or unverified, when the user expects a single definitive answer, or when the application's risk tolerance requires a human to mediate the disagreement before any output reaches the user. In regulated domains such as healthcare or finance, this prompt should be paired with a human approval step and an evidence audit trail to ensure that the presentation of conflict does not inadvertently endorse a harmful or non-compliant position.

Before integrating this prompt, confirm that your upstream conflict detection and source reliability scoring are calibrated. The prompt will faithfully present whatever conflicts it receives, so garbage in means garbage out. Implement a validation step that checks the input for empty conflict lists, duplicate sources, or positions that lack source attribution. If the input fails validation, route to a fallback that informs the user that sources are being reviewed rather than presenting an incomplete or misleading conflict summary. The next step is to wire this prompt into your application harness with structured output parsing, retry logic for malformed responses, and logging that captures which conflicts were presented to which users.

This template structures how your application presents disagreement to users. It forces the model to acknowledge conflict explicitly, attribute each position to its source, and avoid synthesizing a false consensus. The placeholders let you inject your application's specific evidence set, user query, and output constraints. Use this as the core of a user-facing answer generation step, placed after your retrieval and conflict detection pipeline has identified contradictory passages.

textCopy
You are an evidence-aware assistant. Your task is to answer a user's question when the provided sources contain conflicting information.

## USER QUESTION
[USER_QUESTION]

## CONFLICTING EVIDENCE
Below are source passages that disagree with each other. Each passage includes a source identifier and a reliability indicator.

[EVIDENCE_BLOCK]

## OUTPUT INSTRUCTIONS
1. Start by clearly stating that sources disagree on this question.
2. Present each distinct position as a separate section.
3. For each position:
   - Summarize the claim in plain language.
   - List the sources supporting this position with their reliability indicators.
   - Include a brief, direct quote from each source.
4. After presenting all positions, add a "How to Assess This" section that gives the user 2-3 neutral questions they can use to evaluate the evidence themselves (e.g., "Which source is more recent?", "Which source has direct access to the primary data?").
5. Do not declare a winner or state which position is correct.
6. If the evidence is insufficient to characterize any position fairly, say so instead of guessing.
7. Format the response in plain paragraphs with clear headings. Do not use a table.

## CONSTRAINTS
- Never fabricate a resolution when sources genuinely conflict.
- Attribute every claim to a specific source identifier.
- If [RISK_LEVEL] is "high", append: "Consider consulting a subject-matter expert before making a decision based on this information."
- Maintain a neutral, informative tone. Do not advocate for any position.

To adapt this template, start by mapping your retrieval pipeline's output into the [EVIDENCE_BLOCK] placeholder. Each passage should include a source ID, a short reliability label (e.g., "High: peer-reviewed journal, 2024" or "Medium: industry report, 2023"), and the relevant text. If your application already classifies conflict severity or type, inject that metadata as a prefix to each passage. Set [RISK_LEVEL] dynamically based on your domain: use "high" for medical, legal, or financial contexts where a wrong decision carries material harm, and "low" for informational or entertainment use cases. Before shipping, run this prompt against a golden set of known conflicting evidence pairs and check that the output never declares a winner, always attributes claims, and correctly surfaces the "How to Assess This" questions. If the model starts hedging toward one position, add a stronger refusal example to the system prompt or increase the temperature to reduce overconfident synthesis.

This prompt operates at the boundary between evidence synthesis and user-facing output, which makes the implementation harness critical. The prompt expects a structured set of conflicting evidence claims, source metadata, and a presentation strategy as input. Before calling the model, your application must assemble these inputs from upstream retrieval, conflict detection, and source reliability scoring pipelines. The output is a user-facing answer that presents disagreement clearly, so the harness must validate that the response is balanced, properly attributed, and free of false consensus before it reaches a user.

Wire the prompt into a pipeline with three stages: input assembly, model invocation, and output validation. For input assembly, map your conflict detection output into the [CONFLICTING_CLAIMS] placeholder as a JSON array of objects, each containing the claim, source positions, source metadata (name, date, authority score), and conflict type. Populate [PRESENTATION_STRATEGY] from your product policy—options include balanced, weighted_by_authority, or majority_with_dissent. Set [USER_QUESTION] to the original query and [AUDIENCE_EXPERTISE] to guide tone and detail level. For model invocation, use a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Set temperature low (0.1–0.3) to reduce creative drift in neutrality language. Implement a retry wrapper that catches malformed outputs and re-invokes with the error message appended to [CONSTRAINTS]. Log every invocation with the prompt version, input hash, output, and validation result for debugging and audit.

Output validation is the most critical harness component because this prompt directly shapes what users believe about contested information. Build a validator that checks: (1) every position presented is attributed to at least one source from the input; (2) no source is misrepresented—compare presented positions against the input claims using a secondary LLM-as-judge check with a strict rubric; (3) the response does not synthesize a false middle ground or imply consensus where none exists; (4) uncertainty language is present when conflicts are unresolved. For high-stakes domains (healthcare, legal, finance), route outputs through a human review queue before publishing. The review interface should display the original conflicting claims, the model's presentation, and the validation results side by side. Track review decisions to build a feedback dataset for prompt improvement. Avoid wiring this prompt directly into a chatbot response without validation—users will over-trust an unqualified answer, and unresolved conflicts presented as settled facts create liability and trust erosion.