Partial Answer with Caveats Prompt Template

Use the Partial Answer with Caveats prompt when your RAG pipeline retrieves context that is partially relevant but insufficient to fully answer the user's question. This is the middle ground between a confident, fully-grounded answer and a total abstention. The job-to-be-done is to give the user something useful—a partial fact, a directional insight, or a constrained definition—while maintaining strict source fidelity. The ideal user is a product team building customer-facing Q&A systems in domains like technical documentation, legal research, or clinical information where a 'sorry, I don't know' response erodes user trust, but a hallucinated answer creates unacceptable liability. The required context for this prompt is a set of retrieved passages that contain some relevant entities or statements but lack the connective tissue, specific data points, or authoritative confirmation needed for a complete answer.

This prompt belongs in the answer generation step of your RAG pipeline, after retrieval and evidence ranking, and before any post-generation verification or human review handoff. It is not a replacement for retrieval quality improvements. If your retrieval system consistently returns partial matches, invest in query rewriting, chunking strategy, or embedding model selection before relying on this prompt as a patch. The prompt template expects a [CONTEXT] variable containing the ranked, deduplicated passages and an [INPUT] variable with the user's original question. You should also provide an [OUTPUT_SCHEMA] that enforces a structured separation between the 'known' and 'unknown' portions of the answer, typically with fields for the partial answer text, the specific evidence sources supporting each claim, and a list of explicitly identified gaps. For high-stakes domains, add a [RISK_LEVEL] variable that adjusts the caveat language from advisory ('Note: this is incomplete') to mandatory ('WARNING: Do not act on this incomplete information without verification').

Do not use this prompt when the retrieved context is completely empty or entirely irrelevant to the user's question. In that case, an Answer Abstention Trigger Prompt is the correct tool, producing a clean refusal with a gap description rather than a strained partial answer that invents a tangential connection. Similarly, do not use this prompt when the context contains sufficient information for a complete answer but the model is simply failing to synthesize it—that indicates a problem with your synthesis prompt or context window packing, not a need for caveats. Before deploying, test the prompt against a golden dataset of partially-answerable questions and measure two failure modes: false confidence, where the model presents a partial answer as if it were complete, and false abstention, where the model refuses to share genuinely supported information. Wire the output into a validation step that checks whether every claim in the 'known' section has a corresponding source citation, and whether the 'unknown' section accurately reflects the gaps in the provided evidence.

This template is designed for RAG pipelines where providing partial information with clear boundaries is better than total abstention. The prompt instructs the model to synthesize what it can from retrieved context while explicitly marking what remains unknown, uncertain, or unsupported. Use this when your users need actionable partial answers rather than empty refusals, and when your application can display caveat boundaries clearly in the UI.

textCopy
You are an evidence-grounded assistant that answers questions using only the provided context. Your primary responsibility is to separate what is known from what is unknown.

## CONTEXT
[CONTEXT]

## QUESTION
[QUESTION]

## INSTRUCTIONS
1. Identify every claim in the question that can be addressed using the provided context.
2. For claims supported by context, provide a clear answer with inline citations to the specific passage using the format [Source: passage_id].
3. For claims partially supported by context, provide what is known and explicitly mark the boundary where evidence ends using the phrase "[PARTIAL: evidence ends here]".
4. For claims not supported by any context, state "[UNKNOWN: no evidence in provided context]" and do not speculate.
5. For claims where context is ambiguous or contradictory, state "[UNCERTAIN: conflicting evidence between passage_X and passage_Y]" and summarize both positions.
6. Do not introduce any information not present in the context, even if you believe it to be true.
7. Structure your response in three sections:
   - **What We Know**: Supported claims with citations
   - **What Is Uncertain**: Ambiguous or conflicting claims with source references
   - **What We Don't Know**: Unsupported claims with explicit gap descriptions

## OUTPUT FORMAT
[OUTPUT_SCHEMA]

## CONSTRAINTS
- Maximum [MAX_QUOTE_LENGTH] words per direct quote
- Citations must use passage_id values exactly as provided in context
- If the entire question cannot be answered, still provide partial answer for supported portions
- Never fabricate citations or passage_ids

Adapt this template by replacing the square-bracket placeholders with your application's values. [CONTEXT] should contain your retrieved passages with unique passage_id identifiers. [QUESTION] is the user's query. [OUTPUT_SCHEMA] can specify JSON structure, markdown format, or UI component mapping. [MAX_QUOTE_LENGTH] controls verbatim quote limits to avoid copyright or verbosity issues. Before deploying, test this prompt against cases where context is partially relevant, fully irrelevant, and contradictory to verify that caveat boundaries are correctly placed. Pair this with an eval harness that checks caveat accuracy—specifically whether the model correctly identifies what it doesn't know rather than silently omitting unsupported claims.

The Partial Answer with Caveats prompt is designed to sit between retrieval and the user-facing response layer. It should be invoked only after the retrieval step returns at least one passage, but before any answer is shown to the user. The prompt expects three inputs: the original user query, the retrieved context passages with source metadata, and a risk level that controls how aggressively the system should abstain. Wire these inputs through a prompt assembly function that injects them into the [QUERY], [RETRIEVED_CONTEXT], and [RISK_LEVEL] placeholders. The output is a structured JSON object with answer_text, known_facts, unknown_aspects, caveats, and source_map fields. Parse this JSON in your application layer before rendering anything to the user.

Validation is critical for this prompt because partial answers can still contain fabrications. Implement a post-generation check that verifies every claim in known_facts has a corresponding entry in source_map with a valid passage ID. If any claim lacks a source mapping, either trigger the Self-Correction Prompt for Ungrounded Claims or escalate to human review depending on your [RISK_LEVEL] setting. For high-stakes domains, add a second validation pass that checks whether any unknown_aspects entries contradict information actually present in the retrieved context—this catches false abstentions where the model claims ignorance despite having relevant evidence. Log both the raw prompt output and validation results for audit trails.

Model choice matters here. This prompt benefits from models with strong instruction-following and structured output capabilities. Claude 3.5 Sonnet and GPT-4o perform well on the caveat separation task, while smaller models often blur the boundary between known and unknown facts. If you're using an open-weight model, test extensively with your domain's retrieval results and consider fine-tuning on examples that demonstrate clear known/unknown separation. Set a retry policy: if the output fails JSON parsing, retry once with the same prompt. If validation fails on source grounding, retry with the Self-Correction Prompt. If the second attempt still fails, route to a human review queue with the original query, retrieved context, and both failed attempts attached. Never show an unvalidated partial answer to users in regulated domains.