Grounded vs Ungrounded Claim Classifier Prompt Template

This prompt is a production monitoring primitive, not an answer generator. Its job is to classify individual factual claims extracted from a generated answer against a set of provided evidence passages. You should use it inside an observability pipeline that runs asynchronously after responses are generated, feeding structured verdicts into dashboards, alerting systems, or drift detection tools. The ideal user is an evaluation engineer, AI quality lead, or platform engineer responsible for tracking grounding fidelity over time and catching hallucination regressions before they become user-facing incidents.

The classifier requires two pre-processed inputs: a list of discrete factual claims (extracted by a separate claim decomposition step) and a set of evidence passages retrieved for the original query. It returns one of four verdicts per claim: grounded (fully supported by evidence), partially grounded (some support but missing details), ungrounded (no evidence support), or contradicted (evidence directly refutes the claim). This structured output is designed for machine consumption—dashboard ingestion, automated alerts, and trend analysis—rather than human-readable explanations. Wire this into a batch evaluation job that runs on a sample of production traffic, not on every single response, unless you have latency and cost budgets that support it.

Do not use this prompt when you need inline citation verification during answer generation, when you lack a separate claim extraction step, or when your evidence set is empty or irrelevant. It is also not suitable for end-user-facing explanations; the verdicts are coarse labels meant for internal monitoring. If you need fine-grained span alignment between claims and source passages, use the Answer-to-Source Span Alignment prompt instead. If you need a calibrated confidence score rather than discrete verdicts, use the Answer Grounding Confidence Estimation prompt. This classifier is one component in a larger grounding verification stack—pair it with claim extraction upstream and alerting or dashboarding downstream.

This prompt template is designed to be copied directly into your prompt library and wired into a production monitoring pipeline. It accepts a list of extracted claims and a set of evidence passages, then classifies each claim into one of four grounding categories: grounded (fully supported by the evidence), partially grounded (some but not all elements are supported), ungrounded (no evidence support found), or contradicted (evidence directly refutes the claim). The output is a structured JSON report suitable for dashboard ingestion, drift detection, and automated alerting. Replace every square-bracket placeholder with production data before use.

textCopy
You are a claim grounding classifier. Your task is to evaluate each claim against the provided evidence and assign a grounding verdict.

## INPUT
Claims to evaluate:
[CLAIMS_LIST]

Evidence passages:
[EVIDENCE_PASSAGES]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verdict": "grounded | partially_grounded | ungrounded | contradicted",
      "supporting_evidence_ids": ["string"],
      "contradicting_evidence_ids": ["string"],
      "explanation": "string (1-2 sentences explaining the verdict)",
      "confidence": 0.0-1.0
    }
  ],
  "summary": {
    "total_claims": integer,
    "grounded_count": integer,
    "partially_grounded_count": integer,
    "ungrounded_count": integer,
    "contradicted_count": integer
  }
}

## CLASSIFICATION RULES
- **grounded**: Every factual element in the claim is explicitly stated in or directly inferable from the evidence. Cite the specific evidence IDs.
- **partially_grounded**: Some elements are supported but others are missing or unsupported. Identify which parts are grounded and which are not.
- **ungrounded**: No evidence passage supports any part of the claim. Do not guess or infer beyond what the evidence states.
- **contradicted**: At least one evidence passage directly refutes the claim. Cite the contradicting evidence IDs.

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

Return only valid JSON. Do not include markdown fences, commentary, or additional text.

Adaptation guidance: Replace [CLAIMS_LIST] with a JSON array of claim objects, each containing at minimum an id and text field. Replace [EVIDENCE_PASSAGES] with a JSON array of evidence objects, each with an id and content field. The [CONSTRAINTS] placeholder should be populated with domain-specific rules—for example, in healthcare you might add "Do not classify temporal statements as grounded unless the evidence explicitly includes a matching date or time range." The [EXAMPLES] placeholder should contain 3-5 few-shot examples covering each verdict type, including edge cases like claims that appear grounded but use different terminology than the evidence. Set [RISK_LEVEL] to high if this classifier gates user-facing responses, which should trigger additional validation and human review steps in your harness. For low-risk internal monitoring, set it to low and skip the review queue.

The Grounded vs Ungrounded Claim Classifier is designed to operate as a post-generation guardrail inside a production monitoring pipeline, not as a one-off manual check. After your system generates an answer from retrieved evidence, you extract discrete claims from that answer (using a separate extraction step or the Claim-by-Claim Faithfulness Audit template), then pass each claim along with its source evidence to this classifier. The classifier returns a structured JSON verdict per claim: grounded, partially_grounded, ungrounded, or contradicted. This verdict feeds directly into your observability stack—dashboards, drift detectors, and alerting rules—so you can track grounding quality over time and catch regressions before users do.

To wire this into production, wrap the prompt call in a validation-retry-logging harness. First, validate the model's JSON output against a strict schema that requires the verdict field to be one of the four allowed enum values and the evidence_spans array to contain non-empty strings when the verdict is not ungrounded. If validation fails, retry once with the validation error injected into the prompt as additional context. Log every classification attempt—including the input claim, evidence, raw model response, validation result, retry count, and final verdict—to your tracing system (e.g., LangSmith, Braintrust, or custom OpenTelemetry spans). For high-risk domains such as healthcare or legal review, route any contradicted or partially_grounded verdict to a human review queue before the response reaches the end user. Model choice matters here: use a model with strong instruction-following and JSON mode (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro) and set temperature=0 to minimize verdict instability.

The most common production failure mode is evidence-context truncation. If your retrieval pipeline passes long documents and the model's context window clips the relevant passage, the classifier may incorrectly return ungrounded for a claim that is actually supported. Mitigate this by pre-chunking evidence to the specific paragraphs or spans that are most relevant before calling the classifier. A second failure mode is verdict drift when you change the underlying model version—track verdict distributions per model version in your dashboard and run a regression suite of 50–100 labeled claim-evidence pairs before promoting any model or prompt change. Finally, do not use this classifier as a real-time blocking guard if latency is critical; batch classification runs asynchronously after response generation and feed aggregate metrics into your monitoring stack rather than adding synchronous latency to the user-facing path.