Answer Boundary Declaration Prompt Template

This prompt is designed for product teams building customer-facing Q&A systems where the system must clearly separate what it can answer from what it cannot. The core job is to produce an answer that explicitly declares its own boundaries: a 'within scope' section grounded strictly in retrieved context, and an 'outside scope' section that identifies unsupported questions, missing evidence, or topics the system should not address. The ideal user is an AI engineer or product developer integrating a RAG pipeline into a support bot, knowledge base assistant, or compliance-sensitive application where overreach erodes user trust and creates liability.

Use this prompt when the cost of a wrong or overconfident answer is high and the system must signal its limits before the user acts on the output. It is appropriate for regulated domains (healthcare, legal, finance), technical support where incorrect procedures cause harm, and any surface where users might assume the system knows more than it does. Do not use this prompt for open-ended creative generation, casual chat, or low-stakes summarization where boundary precision adds friction without value. The prompt requires structured retrieved context as input—it assumes your retrieval pipeline has already returned passages, and it will not trigger additional searches on its own.

Before deploying, you must define what 'in scope' means for your domain. This is not a generic prompt you can drop in without customization. You will need to configure the [SCOPE_DEFINITION] placeholder with concrete categories your system is authorized to address, and you should pair this prompt with eval checks that measure boundary accuracy and overreach detection. Common failure modes include the model declaring something out of scope that the context actually supports, or failing to flag an unsupported claim because it sounds plausible. Plan to test against a golden set of questions with known scope boundaries before shipping.

This prompt template is the core instruction set for the Answer Boundary Declaration workflow. It is designed to be dropped into a production RAG pipeline immediately after retrieval and before the final answer is surfaced to a user. The template forces the model to partition its response into two explicit sections—'Within Scope' and 'Outside Scope'—making it impossible for the system to blur the line between grounded synthesis and speculation. Use this when your product requires auditable answer boundaries, such as in customer-facing support bots, clinical decision support summaries, or compliance documentation tools.

textCopy
You are an answer-boundary declaration assistant. Your job is to answer the user's question using ONLY the provided context. You must explicitly separate what the context supports from what it does not.

## CONTEXT
[CONTEXT]

## USER QUESTION
[QUESTION]

## INSTRUCTIONS
1. Identify every sub-question or information need present in the user's question.
2. For each sub-question, determine whether the provided context contains sufficient evidence to answer it.
3. Construct your response in two mandatory sections.

## OUTPUT FORMAT
### Within Scope
- Answer every sub-question that the context supports.
- For each claim, include a direct quote from the context as a citation in brackets, e.g., ["exact quote from context"].
- If no sub-questions are fully supported, state: "No part of the question could be answered from the provided context."

### Outside Scope
- List every sub-question that the context does NOT support.
- For each, explain briefly what information is missing and why the context is insufficient.
- If all sub-questions are answered, state: "All parts of the question were answerable from the provided context."

## CONSTRAINTS
- Do not use any knowledge outside the provided context.
- Do not merge the Within Scope and Outside Scope sections.
- If the context is empty, place the entire question in Outside Scope.
- If the question is ambiguous, list the ambiguity in Outside Scope and request clarification.

To adapt this template, replace [CONTEXT] with your retrieved passages and [QUESTION] with the user's raw input. If your application requires a specific JSON schema for downstream rendering, add an [OUTPUT_SCHEMA] placeholder and replace the markdown section instructions with a strict JSON format specification. For high-risk domains, wire the output into a validation step that checks whether any 'Within Scope' claim lacks a bracketed citation. If a citation is missing, either trigger a retry with a stricter prompt or route the response for human review before it reaches the user.