Multi-Turn Answer Consistency Prompt Template

This prompt is for product teams building copilots, chat assistants, and RAG-powered Q&A systems where the user experience depends on answers that remain logically coherent across multiple conversation turns. The core job-to-be-done is preventing the model from contradicting facts it stated in prior responses, which erodes user trust and makes the assistant feel unreliable. The ideal user is an AI engineer or product developer who already has a working RAG pipeline and conversation history management but needs a programmatic guardrail to enforce cross-turn consistency before answers reach the user.

Use this prompt when your assistant operates in a domain where factual consistency matters—technical support, clinical documentation, legal research, financial analysis, or any knowledge base Q&A where users ask follow-up questions that build on previous answers. The prompt requires access to the current user question, the retrieved evidence for this turn, and a structured record of prior assistant answers. It is designed to be inserted as a pre-response check or as part of the answer generation step itself, producing either a consistent answer or a flagged inconsistency with an explanation. Do not use this prompt for single-turn Q&A, creative writing, or open-ended chat where factual precision across turns is not required. It is also not a replacement for proper conversation state management—your application must still handle context window assembly and evidence retrieval.

Before implementing this prompt, ensure your system maintains a reliable record of prior assistant outputs, not just user messages. The prompt's contradiction detection depends on accurate prior-answer context. If your conversation history is lossy or truncated, the consistency check will produce false negatives. For high-stakes domains such as healthcare or legal, this prompt should feed into a human review queue when inconsistencies are flagged, rather than auto-resolving. The next section provides the copy-ready template you can adapt to your output schema and risk tolerance.

This template is designed to be dropped into a multi-turn RAG application where the assistant must maintain factual consistency with its own prior answers. It forces the model to check new claims against a provided conversation history and flag any contradictions before responding. The prompt is structured to be stateless from the model's perspective—all required context, including prior turns and evidence, must be assembled by the application harness and injected into the placeholders.

codeCopy
SYSTEM: You are a precise Q&A assistant operating in a multi-turn conversation. Your primary directive is to answer the current user question using only the provided evidence. Before answering, you must check your proposed response against the provided conversation history to ensure you do not contradict any previously stated facts. If a contradiction is detected, you must flag it explicitly and explain the discrepancy rather than silently overwriting the prior answer.

USER: [CURRENT_QUESTION]

EVIDENCE: [RETRIEVED_CONTEXT]

CONVERSATION HISTORY:
[PRIOR_TURNS]

INSTRUCTIONS:
1. Analyze the EVIDENCE to formulate a draft answer to the CURRENT_QUESTION.
2. Compare every factual claim in your draft answer against the CONVERSATION HISTORY.
3. If all claims are consistent with prior answers, output the final answer in the format specified under OUTPUT_SCHEMA.
4. If any claim contradicts a prior answer, do not output a final answer. Instead, output a CONTRADICTION_FLAG in the specified format, explaining the conflict and citing both the prior statement and the conflicting new evidence.
5. If the EVIDENCE is insufficient to answer the question, output an ABSTENTION response as specified.
6. Do not fabricate information. Do not resolve contradictions by guessing. If sources conflict, surface the conflict.

OUTPUT_SCHEMA:
{
  "status": "consistent" | "contradiction" | "abstention",
  "answer": "The final answer text, only if status is consistent.",
  "citations": [{"source_id": "string", "quote": "relevant excerpt"}],
  "contradiction_flag": {
    "prior_statement": "The exact prior statement from conversation history.",
    "prior_turn_id": "The turn number or identifier.",
    "conflicting_claim": "The new claim that contradicts the prior statement.",
    "conflicting_evidence": "The evidence supporting the new claim.",
    "explanation": "A clear explanation of the discrepancy."
  },
  "abstention_reason": "Explanation of why the evidence is insufficient, only if status is abstention."
}

CONSTRAINTS:
- Never output a final answer if status is contradiction or abstention.
- The contradiction_flag object is required only when status is contradiction.
- Citations must map to source_ids present in the EVIDENCE.
- If the user's question is a follow-up that clarifies a prior ambiguity, treat the clarification as superseding the ambiguous prior context, not as a contradiction.

To adapt this template, replace each square-bracket placeholder with data assembled by your application harness. [CURRENT_QUESTION] receives the latest user message. [RETRIEVED_CONTEXT] should contain the top-k passages from your retrieval pipeline, each with a unique source_id. [PRIOR_TURNS] must be a structured log of previous user questions and assistant answers, including turn identifiers for traceability. The OUTPUT_SCHEMA is a JSON contract—your application should parse this and route the response accordingly: display consistent answers, surface contradiction flags for human review, and treat abstentions as signals to re-retrieve or escalate. For high-stakes domains, always log contradiction events and consider requiring human approval before the assistant can revise a prior answer.

The multi-turn answer consistency prompt is not a standalone component—it must be wired into a broader RAG application harness that manages conversation state, retrieval, validation, and error recovery. In a typical implementation, the prompt receives the current user query, the retrieved evidence for this turn, and a structured representation of prior answers extracted from the conversation history. The application layer is responsible for assembling these inputs, parsing the model's output into a machine-readable format, and routing the result based on the consistency flag. This prompt should be treated as a guardrail component that runs before the final answer is surfaced to the user, not as a replacement for the primary answer generation prompt.

The implementation flow should follow a validate-then-respond pattern. After the primary RAG answer is generated, pass it alongside prior answers and the current evidence into this consistency prompt. Parse the output to extract the consistent boolean, the contradiction_details array, and the revised_answer if a contradiction was detected. If consistent is true, surface the original answer. If consistent is false, log the contradiction details for observability and decide on a recovery path: surface the revised answer directly if confidence is high, flag the response for human review if the contradiction involves regulated or high-stakes content, or trigger a re-retrieval with expanded queries if the evidence appears insufficient. Implement a maximum of two revision attempts before escalating to a human reviewer or surfacing the contradiction transparently to the user with both the original and revised answers.

For production deployment, instrument this prompt with structured logging that captures the prior answer count, contradiction flag, affected claims, and revision latency. Use deterministic JSON parsing with a schema validator—if the model fails to produce valid JSON after one retry, treat the output as a contradiction and escalate. Model choice matters: use a model with strong instruction-following and structured output capabilities (such as GPT-4o, Claude 3.5 Sonnet, or Gemini 2.0 Flash with JSON mode enabled). Set temperature to 0 or near-zero to minimize variance in consistency judgments. For high-throughput systems, consider caching prior answer embeddings and only running the consistency check when the new answer introduces claims that semantically overlap with prior statements—this avoids unnecessary API calls when the user shifts topics. Always include a human-in-the-loop escape hatch for domains where contradictory answers carry legal, clinical, or financial risk, and never silently suppress a contradiction without an audit trail.