Conflict-Resilient Structured Output Prompt

This prompt is designed for API endpoints and backend services that must return a typed, machine-readable response even when the underlying retrieved documents contradict each other. The core job-to-be-done is surfacing disagreement in a structured format that downstream application code can branch on, rather than hiding conflict or silently picking a winner. The ideal user is an AI engineer or backend developer building a RAG system where the consumer is not a human reading free text but another service, a UI component, or a workflow engine that expects a predictable JSON schema. You need this prompt when your product requirements include auditability of source disagreements, per-field confidence scores, and the ability to present alternative values to end users or reviewers.

Before using this prompt, you must already have retrieved context chunks and source metadata available to inject into the template. The prompt assumes you can supply a list of documents with identifiers, timestamps, and authority signals. It also assumes you have defined an output schema that includes fields for resolved values, alternative values, conflict flags, per-field confidence, and source attribution. Without a defined schema, the model will invent its own structure, which defeats the purpose of structured output. You should also have a validation layer ready to check that the model's JSON conforms to your schema before the response reaches downstream systems.

Do not use this prompt for free-text chat responses where a human is reading the output directly and can interpret nuanced conflict language. Do not use it for single-source Q&A where conflict is impossible by definition. Do not use it when the output schema is not yet defined or when your retrieval pipeline cannot provide source-level metadata. This prompt is also a poor fit when latency budgets are extremely tight and the additional tokens required for structured conflict fields would violate your SLA—in those cases, consider a simpler prompt that returns only the top answer with a confidence score, and handle conflict detection in a separate async pipeline. If your use case involves regulated domains like healthcare or legal, pair this prompt with human review checkpoints and evidence grounding requirements built into your harness.

This prompt is designed to be pasted directly into your system instructions or user message for API endpoints that must return typed responses even when sources disagree. It forces the model to produce a single valid JSON object matching the output contract below, with explicit fields for conflict state, alternative values, confidence per field, and source attribution. The schema handles both resolved and unresolved conflict states within the same structure, so your downstream application code doesn't need to branch on response shape.

textCopy
You are a structured output generator for a RAG system. Your task is to answer the user's question using only the provided retrieved context. You must return a single valid JSON object that follows the output schema exactly.

## INPUT
Question: [USER_QUESTION]
Retrieved Context:
[RETRIEVED_DOCUMENTS]

## OUTPUT SCHEMA
Return a JSON object with these fields:
- "answer": string or null. The best answer given the evidence. Null if no answer can be determined.
- "conflict_detected": boolean. True if sources contradict each other on material facts.
- "conflict_type": string or null. One of "resolved", "unresolved", "temporal", "definitional", "numerical", or null if no conflict.
- "conflict_description": string or null. Plain-language summary of the disagreement.
- "resolved_value": string or null. The value chosen after resolving the conflict, with brief justification.
- "alternative_values": array of objects or empty array. Each object has "value" (string), "source_ids" (array of strings), and "reason_rejected" (string or null).
- "confidence": number between 0.0 and 1.0. Overall confidence in the answer.
- "field_confidence": object. Keys are field names from the answer, values are numbers 0.0-1.0.
- "source_attribution": array of objects. Each has "source_id" (string), "claim" (string excerpt from source), and "relevance" ("supporting" | "conflicting" | "neutral").
- "abstention_recommended": boolean. True if the system should refuse to answer or escalate.
- "abstention_reason": string or null. Why abstention is recommended.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## INSTRUCTIONS
1. Read all retrieved context carefully.
2. Identify whether sources agree or disagree on material facts.
3. If sources conflict, populate conflict fields and include all alternative values with their source IDs.
4. If you can resolve the conflict (e.g., newer source supersedes older, more authoritative source outweighs less authoritative), set conflict_type to "resolved" and populate resolved_value.
5. If you cannot resolve the conflict, set conflict_type to "unresolved" and leave resolved_value as null.
6. Assign confidence scores honestly. Low agreement or low-quality sources should reduce confidence.
7. If confidence is below [ABSTENTION_THRESHOLD], set abstention_recommended to true.
8. Return ONLY the JSON object. No markdown fences, no commentary.

To adapt this prompt, replace the square-bracket placeholders with your specific inputs. [USER_QUESTION] is the end user's query. [RETRIEVED_DOCUMENTS] should contain your retrieved passages with source IDs, formatted consistently—each document needs a stable identifier for the source_attribution array to reference. [CONSTRAINTS] is where you add domain-specific rules: for legal use, you might require jurisdiction precedence; for financial data, you might specify rounding rules and tolerance bands. [EXAMPLES] should include at least one resolved-conflict example and one unresolved-conflict example so the model sees both paths. [ABSTENTION_THRESHOLD] is a number like 0.6—set this based on your risk tolerance. Before deploying, validate the output against the schema in your application layer and run eval cases that include known contradictory document pairs to confirm the model populates alternative_values and conflict_detected correctly.

This prompt is designed for API endpoints that must return a typed, machine-readable response even when retrieved sources disagree. The harness around the prompt is responsible for enforcing the output schema, validating conflict fields, and deciding what the application does when the model returns unresolved conflicts. Treat the prompt as one component in a pipeline that includes schema validation, retry logic, and downstream routing based on conflict severity.

Start by defining the expected output schema in your application code, not just in the prompt. Use a library like Pydantic (Python), Zod (TypeScript), or JSON Schema validators to enforce that every response contains the required fields: resolved_value, conflict_flag, alternative_values, confidence_per_field, and source_attribution. After the model returns a response, validate it immediately. If validation fails, retry once with the same prompt and a brief error message appended to the input context describing which field was missing or malformed. Do not retry more than twice; after two failures, return a structured error payload with conflict_flag: true and an error field so the caller can degrade gracefully.

For high-stakes domains—legal, clinical, financial—route responses with conflict_flag: true or confidence_per_field below your defined threshold to a human review queue. The harness should check these flags before the response reaches the end user or downstream system. Log every response, including the raw model output, validation result, retry count, and final payload, so you can trace conflict patterns and tune thresholds over time. Model choice matters here: prefer models with strong instruction-following and structured output support (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro with response_schema enabled). Avoid smaller or older models that drift toward narrative answers instead of typed conflict structures.

When wiring this into a RAG pipeline, pass the retrieved documents as a structured list with explicit source IDs, timestamps, and credibility metadata. The prompt's conflict detection depends on the harness providing clean, distinguishable source records. If your retrieval system returns duplicate or near-duplicate passages, deduplicate before calling this prompt to avoid false conflict signals. Finally, build an eval harness that tests the prompt against curated conflict cases—known contradictory document pairs, single-source inputs, and edge cases with three or more conflicting sources—and measure both schema compliance and conflict detection accuracy before shipping.