Sentence-Level Attribution Verification Prompt Template

This prompt is designed for evaluation engineers and AI quality teams who need to verify that every sentence in a generated answer is fully supported by provided source evidence. It performs a fine-grained grounding audit by independently checking each sentence against the full evidence set, assigning an attribution confidence score, and flagging sentences that combine information from multiple sources without clear provenance. Use this prompt in regulated domains such as legal, healthcare, and finance where unsupported claims carry compliance risk, or in any production RAG pipeline where hallucination detection must operate at the sentence level before responses reach users.

This is not a prompt for generating answers. It is a verification prompt that runs after answer generation, consuming the answer and the evidence set to produce a structured audit report. The ideal user is someone building an output validation pipeline, a guardrail system, or an evaluation harness. You should have the generated answer and the full set of retrieved evidence passages available before invoking this prompt. The prompt expects each evidence passage to include a unique identifier so the audit report can trace attributions back to specific sources. Do not use this prompt when the evidence set is empty, when the answer is a single word or phrase with no compositional structure, or when you need real-time streaming verification—this prompt works best in batch or post-generation review workflows.

Before deploying this prompt, define your confidence thresholds and decide what action the system takes when a sentence falls below the acceptable attribution score. In high-risk domains, sentences flagged as ungrounded or multi-source without clear provenance should trigger human review, not automatic suppression. Pair this prompt with the Unsupported Statement Flagging Prompt Template if you need inline annotations for downstream guardrails, or with the Hallucination Risk Scoring Prompt Template if you need a broader risk assessment before sentence-level audit. Start by running this prompt against a golden dataset of known grounded and ungrounded answer-evidence pairs to calibrate your confidence score interpretation before putting it in front of users.

This template performs a sentence-level attribution audit. It takes a generated answer and a set of evidence passages, then independently verifies each sentence. For each sentence, the model must determine whether it is fully grounded in the evidence, partially grounded, ungrounded, or contradicted. The prompt is designed for regulated domains—legal, clinical, financial—where a single unsupported sentence can create audit risk. Before using this template, ensure your evidence set is complete and that you have already filtered irrelevant passages. This prompt does not retrieve evidence; it only verifies against what you provide.

textCopy
You are an attribution verification auditor. Your task is to verify each sentence in the provided answer against the evidence set. You must operate with high precision and flag any sentence that cannot be fully traced to the evidence.

## INPUT

**ANSWER TO VERIFY:**
[ANSWER_TEXT]

**EVIDENCE SET:**
[EVIDENCE_PASSAGES]

**VERIFICATION RULES:**
[CONSTRAINTS]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "answer_id": "[ANSWER_ID]",
  "verification_date": "[VERIFICATION_DATE]",
  "sentences": [
    {
      "sentence_index": 0,
      "sentence_text": "string",
      "attribution_verdict": "fully_grounded | partially_grounded | ungrounded | contradicted",
      "confidence": 0.0-1.0,
      "supporting_evidence_ids": ["string"],
      "supporting_evidence_excerpts": ["string"],
      "unsupported_spans": ["string"],
      "contradicting_evidence_ids": ["string"],
      "contradicting_evidence_excerpts": ["string"],
      "multi_source_flag": true/false,
      "provenance_notes": "string"
    }
  ],
  "overall_faithfulness_score": 0.0-1.0,
  "critical_flags": ["string"]
}

## VERIFICATION PROCEDURE

1. Split the answer into individual sentences. Treat semicolons and bullet points as sentence boundaries when they express independent claims.
2. For each sentence, search the evidence set for support. A sentence is fully_grounded only if every factual claim within it can be traced to at least one evidence passage.
3. If a sentence combines information from multiple sources, set multi_source_flag to true and document which parts come from which source in provenance_notes.
4. If a sentence contains any claim not found in the evidence, mark it as partially_grounded (some support exists) or ungrounded (no support exists). List the unsupported spans explicitly.
5. If a sentence directly contradicts evidence, mark it as contradicted and cite the contradicting passages.
6. Assign confidence based on how directly the evidence supports the claim. Indirect or inferential support should reduce confidence.
7. Add critical_flags for any sentence marked ungrounded, contradicted, or with confidence below [CONFIDENCE_THRESHOLD].

## EXAMPLES

**Example 1: Fully Grounded Sentence**
Evidence: "The patient was prescribed 50mg of metoprolol on March 3, 2024."
Answer sentence: "The patient received 50mg of metoprolol on March 3, 2024."
Verdict: fully_grounded, confidence: 0.98

**Example 2: Partially Grounded Sentence**
Evidence: "The patient reported mild headache."
Answer sentence: "The patient reported mild headache that resolved with acetaminophen."
Verdict: partially_grounded, unsupported_spans: ["that resolved with acetaminophen"], confidence: 0.6

**Example 3: Contradicted Sentence**
Evidence: "Lab results showed potassium at 4.2 mmol/L."
Answer sentence: "Lab results showed potassium at 3.1 mmol/L."
Verdict: contradicted, contradicting_evidence_excerpts: ["potassium at 4.2 mmol/L"], confidence: 0.95

**Example 4: Multi-Source Sentence**
Evidence A: "The defendant was seen at 8:15 PM."
Evidence B: "The incident occurred at 8:30 PM."
Answer sentence: "The defendant was seen 15 minutes before the incident."
Verdict: fully_grounded, multi_source_flag: true, provenance_notes: "Time gap computed from Evidence A timestamp and Evidence B timestamp."

## CONSTRAINTS

- Do not infer support. If evidence is missing, mark the sentence as ungrounded or partially_grounded.
- Do not correct the answer. Your job is verification, not rewriting.
- If a sentence is ambiguous, note the ambiguity in provenance_notes and reduce confidence.
- Treat numerical values, dates, names, and dosages as high-precision claims. Any mismatch is a contradiction.
- If the evidence set is empty or insufficient to verify any sentence, return an empty sentences array with critical_flags: ["INSUFFICIENT_EVIDENCE"].

To adapt this template, replace [ANSWER_TEXT] with the generated answer you need to audit and [EVIDENCE_PASSAGES] with your retrieved or provided evidence. Each evidence passage should include a unique ID so the model can reference it in supporting_evidence_ids and contradicting_evidence_ids. Set [CONSTRAINTS] to domain-specific rules—for example, in clinical contexts you might add 'Any mismatch in medication dosage, lab value, or patient identifier is a critical contradiction regardless of magnitude.' Set [CONFIDENCE_THRESHOLD] to your risk tolerance; 0.7 is a common starting point for regulated domains. The [ANSWER_ID] and [VERIFICATION_DATE] fields are metadata you inject from your application layer, not from the model.

Before deploying this prompt in production, run it against a golden dataset of known grounded and ungrounded answer-evidence pairs. Measure inter-rater agreement between this prompt and human annotators on at least 50 examples. Pay special attention to partially_grounded sentences—these are the most common source of disagreement and the most likely to slip through if your threshold is too permissive. If your domain requires human review for any ungrounded or contradicted sentence, route those outputs to a review queue rather than blocking the entire response. For high-throughput systems, consider batching sentences from multiple answers into a single verification call to reduce latency, but ensure each sentence retains its answer_id and sentence_index for traceability.

This prompt is designed to operate as a post-generation verification step, not as a real-time chat interaction. In a typical pipeline, a primary model generates an answer from retrieved evidence, and this prompt audits that answer sentence-by-sentence before it reaches the user. The harness must receive the full generated answer and the complete evidence set as inputs, then parse the structured JSON output for automated decision-making. The primary integration points are: (1) an evaluation harness for offline quality measurement, (2) a pre-release guardrail that blocks or flags low-attribution responses, and (3) a production monitoring pipeline that logs attribution scores for drift detection.

Validation and schema enforcement are critical because the prompt returns a JSON object with an array of per-sentence verdicts. Your harness should validate that every sentence from the input answer appears in the output, that attribution_confidence values are numeric and within expected ranges, and that evidence_references contain valid indices into the provided evidence set. Implement a retry loop: if validation fails (missing sentences, malformed JSON, out-of-range indices), re-invoke the prompt with the same inputs and an explicit error message appended to the system instruction. Cap retries at 3 attempts before escalating to human review or logging the failure for offline analysis. For high-risk domains, add a human approval gate when any sentence receives an attribution_confidence below a configurable threshold (e.g., 0.7) or when flags contains multi_source_merge or unsupported_claim.

Model choice and latency budgeting matter here. This verification step adds latency to your response pipeline, so select a model that balances accuracy and speed. For offline evaluation, use a capable model like GPT-4 or Claude 3.5 Sonnet to establish ground-truth attribution labels. For production guardrails, consider a faster model (GPT-4o-mini, Claude 3 Haiku) if your latency budget is tight, but validate that the smaller model's attribution judgments correlate sufficiently with your evaluation baseline. Log every invocation—input answer, evidence set, raw model output, parsed verdicts, and any validation errors—to enable trace analysis when users report hallucination issues. Store these logs indexed by response_id so you can replay failed verifications and improve the prompt over time.

Tool integration and RAG coupling are straightforward here because this prompt is purely text-in, JSON-out. It does not call external tools or retrieve additional evidence. However, your upstream RAG pipeline must pass the same evidence passages that were used during answer generation. If your retriever re-ranks or truncates evidence between generation and verification, you will get false-positive unsupported-claim flags. Freeze the evidence set at generation time and pass it unchanged to this verification step. For multi-turn conversations, verify only the latest assistant message against the evidence retrieved for that turn, not the entire conversation history, unless prior turns introduced new evidence that remains relevant.

What to avoid: Do not use this prompt as the sole defense against hallucination in customer-facing systems without human review for high-severity domains. Do not skip output validation—the model can still return malformed JSON or miss sentences. Do not set attribution_confidence thresholds without calibrating them against human judgments on your specific domain data. Start with an offline evaluation run on 100+ answer-evidence pairs, compare model-assigned confidence scores to human annotator verdicts, and set thresholds based on your acceptable false-positive and false-negative rates. Finally, monitor attribution score distributions in production; a sudden drop in average confidence often signals a retriever regression or evidence staleness problem before users notice.