Citation Grounding Verification Prompt

This prompt is designed for a single, high-stakes job: verifying whether a source document actually supports a specific statement. It is built for documentation, legal, and compliance product teams who cannot afford to ship AI-generated content that misrepresents its sources. The primary user is an engineering lead or product manager integrating a verification step into a RAG pipeline, a contract review system, or a clinical documentation workflow. The prompt takes two required inputs—a statement and the full text of its claimed source—and returns a structured verdict of grounded, ungrounded, or partially-grounded, backed by direct quotes from the source.

Do not use this prompt when you need to verify a statement against a large corpus of documents in a single call. This prompt is designed for a one-to-one statement-to-source verification. For multi-document synthesis, use a Source-Attribution Audit Prompt. Do not use it to generate content or answer questions; its sole purpose is post-generation factuality enforcement. The prompt is also unsuitable for verifying subjective interpretations or opinions, as it is designed to check factual support, not argumentative validity. The required inputs are non-negotiable: without both the statement and the source text, the model will hallucinate a verification, defeating the entire purpose.

Before integrating this prompt into a production harness, you must define your tolerance for partial grounding. A statement that is 'partially-grounded' might be acceptable for an internal research brief but must be treated as a failure for a legal filing. The prompt's output schema includes a verdict field and a rationale with quotes, making it straightforward to write a downstream rule that routes ungrounded and partially-grounded results for human review. The next step is to copy the prompt template, adapt the risk-level instructions, and wire it into a validation loop that blocks ungrounded claims from reaching end users.

This prompt template is designed to be dropped directly into your application's verification pipeline. It accepts a statement and its claimed source text, then produces a structured verdict with supporting quotations. The template uses square-bracket placeholders that your application must populate before sending the request to the model. Every placeholder maps to a required input your system must provide—no defaults are assumed, and missing inputs will produce unreliable verdicts.

textCopy
You are a citation verification specialist. Your job is to determine whether a source document supports a given statement.

## INPUT

**Statement to verify:**
[STATEMENT]

**Claimed source text:**
[SOURCE_TEXT]

**Source metadata (optional):**
[SOURCE_METADATA]

## INSTRUCTIONS

1. Read the statement carefully. Identify every factual claim it makes.
2. Read the source text. Search for evidence that directly supports, partially supports, or contradicts each claim.
3. Do not infer support. If the source implies something but does not state it explicitly, treat that claim as ungrounded.
4. If the source is silent on a claim—neither supporting nor contradicting it—treat that claim as ungrounded.
5. For each claim you find supported, quote the exact passage from the source that provides the evidence.

## OUTPUT FORMAT

Return a JSON object with this exact schema:

{
  "verdict": "grounded" | "partially_grounded" | "ungrounded",
  "confidence": 0.0-1.0,
  "claims": [
    {
      "claim_text": "string",
      "status": "supported" | "contradicted" | "unsupported" | "silent",
      "source_quote": "string or null",
      "explanation": "string"
    }
  ],
  "summary": "One-sentence summary of the verification result."
}

## CONSTRAINTS

- Never fabricate source quotes. If no quote exists, set source_quote to null.
- If the source contradicts the statement, verdict must be "ungrounded".
- If any claim is unsupported or silent, verdict cannot be "grounded".
- Quote source text verbatim. Do not paraphrase inside source_quote.
- If [SOURCE_METADATA] is empty, ignore it.
- Set confidence based on how clearly the source evidence maps to the claims.

To adapt this template for your system, replace each placeholder with real data at runtime. [STATEMENT] should contain the exact text you need verified—do not summarize or rewrite it before passing it in. [SOURCE_TEXT] must be the full source passage, not a snippet or summary; truncated sources produce false negatives. [SOURCE_METADATA] is optional but useful for logging and audit trails—pass document titles, page numbers, or retrieval IDs when available. If your application needs a different output schema, modify the JSON structure in the OUTPUT FORMAT section, but preserve the verdict, claims, and source_quote fields as the minimum viable verification surface. For high-risk domains such as legal, healthcare, or financial compliance, always route partially_grounded and ungrounded verdicts to a human review queue before the output reaches users or databases.

The Citation Grounding Verification Prompt is designed to operate as a post-generation validation step in a RAG pipeline, documentation system, or legal review workflow. It should be called after a model generates a statement and claims a source, but before that statement reaches a user, database, or downstream system. The prompt requires two inputs: the statement to verify and the full source text. Both must be provided together in a single request. Do not rely on the model to retrieve the source itself—this prompt performs verification, not retrieval. The output is a structured verdict (grounded, ungrounded, or partially-grounded) with quoted evidence from the source text that supports or contradicts the statement.

Wire this prompt into your application as a synchronous validation step with a strict timeout and a retry budget. After receiving the model's verdict, validate the output structure before acting on it: check that the verdict field contains exactly one of the three allowed values, that the evidence array is present and contains non-empty quote strings when the verdict is grounded or partially-grounded, and that the explanation field is a non-empty string. If the output fails structural validation, retry once with the same inputs and a stronger constraint instruction appended. If the second attempt also fails, escalate to a human review queue with the original statement, source text, and both failed outputs attached. Log every verification attempt—including the statement, source, model response, validation result, and final disposition—for auditability and prompt performance tracking over time.

For high-risk domains such as legal, healthcare, or financial compliance, always route partially-grounded and ungrounded verdicts to a human reviewer before taking any automated action. Even grounded verdicts should be sampled for human review at a configurable rate (start at 10% and adjust based on observed accuracy). Choose a model with strong instruction-following and low hallucination rates for this task—frontier models from major providers are appropriate, while smaller or older models may produce unreliable verdicts. Avoid using this prompt with streaming responses; the full structured output must be received and parsed before the verification result can be trusted. If your pipeline processes high volumes, batch statements against their sources and run verifications in parallel, but keep each verification independent to prevent cross-contamination between source texts.