Answer Abstention Trigger Prompt Template

This prompt is designed for operators of high-stakes Retrieval-Augmented Generation (RAG) systems where a wrong answer is significantly worse than no answer. The ideal user is an AI engineer or technical product manager responsible for a system in clinical, legal, financial, or compliance workflows. The required context is a post-retrieval, pre-response step where the model has access to a set of retrieved passages and the user's question. The prompt's job is to force a structured refusal with a specific gap description whenever the evidence is insufficient, irrelevant, or contradictory, preventing the model from hallucinating a plausible-sounding but unfounded response.

You should use this prompt when you have already built a retrieval pipeline and need a reliable guardrail at the answer generation stage. It is not a replacement for retrieval quality improvements or a general-purpose safety filter. Do not use this prompt when a conversational, speculative, or creative response is acceptable, or when the cost of abstention (e.g., user drop-off in a low-stakes FAQ bot) outweighs the risk of a minor hallucination. It is also inappropriate for systems where the user expects the model to synthesize an answer from its internal knowledge when retrieval fails; this prompt explicitly forbids that behavior.

Before implementing, you must define what constitutes 'insufficient' evidence for your use case. A clinical decision support tool might require multiple high-quality studies, while an internal IT helpdesk bot might only need a single relevant paragraph. Wire this prompt into your application's answer generation step, directly after retrieval. The output should be parsed by your application logic: a valid answer can be shown to the user, while a refusal object should trigger an alternative workflow, such as escalating to a human, re-running retrieval with a rewritten query, or simply informing the user that the information is not available. The next section provides the exact prompt template to adapt.

This template implements a strict evidence-grounding policy for high-stakes RAG systems. It forces the model to assess whether the provided context passages contain sufficient, relevant, and non-contradictory evidence before generating any answer. When evidence is insufficient, the model must produce a structured refusal with a specific gap description rather than guessing or fabricating plausible-sounding information. This is essential for healthcare, legal, finance, and compliance applications where wrong answers are worse than no answer.

textCopy
You are an answer generation system with a strict evidence-grounding policy. Your primary directive is to answer the user's question using ONLY the provided context passages. If the context does not contain sufficient evidence to answer the question fully and accurately, you MUST refuse to answer and explain what is missing.

## CONTEXT PASSAGES
[RETRIEVED_CONTEXT]

## USER QUESTION
[USER_QUESTION]

## OUTPUT INSTRUCTIONS
1. Assess whether the context passages contain sufficient, relevant, and non-contradictory evidence to answer the user's question.
2. If evidence is sufficient, produce an answer grounded strictly in the context. Every factual claim must be traceable to a specific passage.
3. If evidence is insufficient, produce a structured refusal response.

## REFUSAL CRITERIA
Refuse to answer if ANY of the following conditions are true:
- The context passages do not address the question.
- The context passages address the question only partially, and the missing information is material to a correct answer.
- The context passages contradict each other on material facts, and no resolution is possible from the evidence.
- The context passages are too vague, ambiguous, or low-quality to support a reliable answer.
- The question requires information outside the scope of the provided context.

## REFUSAL RESPONSE FORMAT
When refusing, output a JSON object with the following structure:
{
  "status": "refused",
  "refusal_reason": "[INSUFFICIENT_EVIDENCE | CONTRADICTORY_EVIDENCE | OUT_OF_SCOPE | AMBIGUOUS_EVIDENCE]",
  "gap_description": "Specific description of what information is missing or why the evidence is insufficient.",
  "context_summary": "Brief summary of what the retrieved context does contain relevant to the question.",
  "suggested_next_steps": "Optional suggestion for how the user might rephrase or where they might find the answer."
}

## ANSWER RESPONSE FORMAT
When answering, output a JSON object with the following structure:
{
  "status": "answered",
  "answer": "The grounded answer text.",
  "citations": [{"passage_id": "[ID]", "relevant_text": "[QUOTED_TEXT]"}]
}

## CONSTRAINTS
- Do not use knowledge outside the provided context passages.
- Do not guess, infer beyond the evidence, or fill gaps with plausible-sounding information.
- If you are uncertain whether evidence is sufficient, default to refusal.
- Output ONLY the JSON object. No preamble, no commentary.

To adapt this template, replace [RETRIEVED_CONTEXT] with your actual retrieved passages, each tagged with a unique passage_id that the model can reference in citations. Replace [USER_QUESTION] with the end user's query. The refusal criteria can be tightened or loosened depending on your risk tolerance—for example, you might add a criterion for stale evidence if your knowledge base has temporal requirements. The JSON output schema is designed for programmatic consumption: your application layer should parse the status field to route answers to users and refusals to a review queue or fallback retrieval step.

Before deploying, run this prompt through an eval harness that measures both false abstention rate (refusing when evidence was actually sufficient) and false confidence rate (answering when evidence was insufficient). Use a golden dataset of questions paired with retrieval results where you've manually labeled whether the context supports a correct answer. For high-risk domains, add a human review step for all refusals to confirm the gap description is accurate and the system isn't missing retrievable evidence. Monitor production logs for patterns in refusal_reason values—frequent INSUFFICIENT_EVIDENCE refusals may indicate retrieval pipeline problems rather than prompt problems.

The Answer Abstention Trigger prompt is a critical safety component that sits between retrieval and the user-facing response. It must be treated as a structured decision point, not a free-text generation step. The harness should parse the model's JSON output and route based on the status field: answered responses proceed to the answer synthesis prompt, while refused responses bypass generation entirely and return a controlled refusal payload to the user. Never expose raw model output directly—every response must pass through parsing, validation, and routing logic before reaching the user interface.

For refused responses, log the gap_description and context_summary fields to your retrieval quality monitoring system. These structured refusal reasons are invaluable for diagnosing retrieval gaps, chunking failures, and embedding drift over time. For answered responses, validate that every passage_id in the citation array exists in the input context before displaying the answer to the user. If a citation references a non-existent passage, treat it as a fabrication and either trigger a retry or escalate to human review depending on your risk tolerance. Implement a JSON repair retry policy: if the model outputs malformed JSON, retry once with a repair prompt that includes the raw output and a request to fix the structure. If the second attempt also fails, log the failure and route to a fallback response.

Monitor for two critical failure modes: false confidence (the model answers when it should refuse) and false abstention (the model refuses when sufficient evidence exists). Log both cases for eval dataset expansion. In high-stakes domains such as healthcare, legal, or finance, route all refused responses to a human review queue with the original question, retrieved context, and the full refusal payload. The reviewer can override the abstention, trigger additional retrieval, or confirm the refusal. This human-in-the-loop step ensures that critical questions are never silently dropped while maintaining the safety benefits of automated abstention.