Sentence-Level Grounding Check Prompt

This prompt is designed for a specific, high-precision job: evaluating every sentence in a generated answer against a provided source context to determine if it is grounded in evidence. The primary user is a QA engineer or an eval pipeline builder who needs to move beyond a holistic 'does this look right?' review and into a fine-grained, auditable verification process. The ideal scenario is a post-generation guardrail in a RAG system, where an LLM has produced an answer and you need to programmatically identify exactly which sentences are safe to show a user and which contain unsupported fabrications. It is also highly effective as a debugging tool during prompt engineering, allowing you to see precisely where your generation prompt is causing the model to hallucinate, and as part of an automated regression test suite to catch factual regressions before they ship.

For this prompt to be effective, the generated answer must contain discrete, verifiable factual claims. It works best on expository or analytical text, such as summaries, reports, or direct answers to questions. The source context must be sufficiently rich to make a grounding judgment; if the provided context is sparse or only tangentially related to the answer, the prompt will correctly flag most sentences as ungrounded, which is a true signal about your retrieval pipeline, not a failure of the grounding check itself. You must provide the full generated answer and the complete source context as inputs. The output is a structured, sentence-by-sentence grounding map, typically a JSON array where each element contains the original sentence and a verdict like GROUNDED or UNGROUNDED, often with a brief rationale pointing to the specific source span. This structure allows for surgical removal or highlighting of fabricated details in a user interface.

Do not use this prompt when the generated answer is purely stylistic, conversational, or subjective, such as an open-ended creative story, a greeting, or an empathetic response where there is no factual claim to verify. It is also the wrong tool for evaluating the overall quality, tone, or helpfulness of an answer; its sole focus is factual grounding. If your goal is to check if a citation points to a real source that actually supports the claim, use the Citation-to-Evidence Cross-Reference Prompt instead. If you need to classify the type of hallucination (e.g., fabrication vs. unsupported inference), use the Faithful Synthesis vs. Fabrication Classification Prompt. This prompt is your scalpel for isolating unsupported sentences; use it when you need a precise, claim-level grounding map before an answer reaches a user or as a high-signal metric in your evaluation suite.

This prompt template is the core engine of your sentence-level hallucination detection pipeline. It instructs the model to evaluate each sentence in a generated answer against the provided source context, producing a structured grounding map. The template uses square-bracket placeholders for all dynamic inputs—replace these with your application's data before sending the request to the model. The output is a JSON object that maps each sentence to a grounding verdict, enabling precise, automated removal or flagging of fabricated details.

textCopy
You are a precise factual auditor. Your task is to evaluate each sentence in the provided [ANSWER] against the [CONTEXT] to determine if it is factually grounded.

## INPUT
**Context:**
[CONTEXT]

**Answer to Audit:**
[ANSWER]

## INSTRUCTIONS
1. Split the answer into individual sentences. Use the sentence boundaries exactly as they appear in the answer.
2. For each sentence, determine if all its factual claims are directly supported by the provided context.
3. Classify each sentence into one of three categories:
   - **GROUNDED**: Every factual claim in the sentence is explicitly stated in or directly inferable from the context.
   - **UNSUPPORTED**: The sentence contains at least one factual claim that is not present in the context. This includes invented names, numbers, dates, events, or causal relationships.
   - **CONTRADICTED**: The sentence makes a claim that directly conflicts with information in the context.
4. For UNSUPPORTED or CONTRADICTED sentences, provide a brief reason explaining what is wrong and, if applicable, quote the conflicting context.

## CONSTRAINTS
- Do not judge the quality, style, or fluency of the answer. Only assess factual grounding.
- If the context is empty or contains no relevant information, classify all sentences as UNSUPPORTED.
- If a sentence is a subjective opinion, a question, or purely conversational, classify it as GROUNDED only if the context supports the conversational act itself.
- Do not use outside knowledge. Base your judgment solely on the provided context.

## OUTPUT SCHEMA
Return a valid JSON object with the following structure. Do not include any text outside the JSON object.
{
  "sentences": [
    {
      "index": 0,
      "text": "The exact sentence from the answer.",
      "verdict": "GROUNDED",
      "reason": null
    },
    {
      "index": 1,
      "text": "Another sentence.",
      "verdict": "UNSUPPORTED",
      "reason": "Claims the release date is June 2024, but the context only mentions a Q3 2024 release window."
    }
  ],
  "summary": {
    "total_sentences": 5,
    "grounded_count": 3,
    "unsupported_count": 1,
    "contradicted_count": 1
  }
}

To adapt this template for your application, replace the placeholders as follows: [CONTEXT] with the retrieved passages, formatted with their identifiers (e.g., [Doc-1] ...). [ANSWER] with the full generated response you need to audit. [OUTPUT_SCHEMA] can be left as-is or replaced with a custom schema if your downstream pipeline requires different field names. For high-risk deployments, add a [RISK_LEVEL] placeholder that adjusts the strictness of the grounding criteria—for example, in a clinical setting, you might require verbatim support rather than reasonable inference. After replacing the placeholders, validate that the output JSON conforms to your expected schema before processing the grounding map. A single malformed output should trigger a retry with a repair prompt, not a silent failure.

The Sentence-Level Grounding Check prompt is designed to operate as a post-generation validation step within a RAG pipeline, sitting between answer synthesis and user delivery. Its primary job is to accept a generated answer and the retrieved context that was used to produce it, then return a structured map indicating whether each sentence is grounded in that context. This harness is not a standalone chatbot; it is a programmatic guardrail that should be called synchronously after every answer generation, with its output dictating whether the answer is released, flagged for review, or automatically repaired.

To wire this prompt into an application, first split the generated answer into sentences using a deterministic sentence tokenizer (e.g., NLTK's sent_tokenize or spaCy's sentence boundary detection) before calling the model. Pass the tokenized sentence list alongside the full retrieved context into the prompt template. The model should return a JSON object mapping each sentence index to a grounding verdict (GROUNDED, PARTIALLY_GROUNDED, or UNSUPPORTED) and the specific source span that supports it. Implement a strict JSON schema validator on the model's response; if the output fails to parse or is missing sentence indices, retry once with a stronger format constraint. Log every validation failure and the final verdict map for observability. For high-stakes domains, route any answer containing one or more UNSUPPORTED sentences to a human review queue rather than blocking silently.

Choose a model with strong instruction-following and JSON mode support for this task, as structured output reliability is critical. GPT-4o and Claude 3.5 Sonnet are good defaults. Set temperature to 0 to minimize variability in verdicts. If your application has strict latency requirements, consider batching multiple answers in a single call, but ensure the prompt clearly separates each answer-context pair to avoid cross-contamination. Avoid using this check on answers shorter than two sentences, as single-sentence outputs often produce ambiguous grounding signals. The next step after implementing this harness is to build a dashboard that tracks grounding pass rates over time, alerting you when hallucination rates drift upward—often a sign that your retrieval pipeline needs attention.