Evidence Grounding Requirement Prompt

This prompt is built for AI engineers and product teams operating factual-domain assistants where every claim must be traceable to retrieved evidence. It functions as a post-generation or pre-release enforcement layer that audits assistant statements across multiple turns, checking whether each claim remains grounded in the provided sources. The primary job-to-be-done is automated grounding verification: you feed in the conversation history, the evidence set, and your grounding policy, and the prompt returns a structured score, a list of ungrounded claims, and remediation instructions. This is not a RAG answer-generation prompt. It does not produce user-facing responses. It validates them before they ship.

Use this prompt when you need a programmatic grounding audit that can be wired into a CI-like eval harness, a pre-release review queue, or an automated guardrail before a response reaches the user. It is appropriate for assistants in regulated domains, internal knowledge-base Q&A, clinical documentation review, financial analysis, and any product where hallucinated claims carry material risk. The prompt expects several inputs: the full conversation history or a window of recent turns, the evidence passages retrieved for those turns, and a grounding policy that defines what counts as a supported claim versus speculation. You should also provide an output schema so the audit result is machine-readable and can trigger downstream actions like blocking, flagging for human review, or re-prompting with stricter instructions.

Do not use this prompt when you need real-time answer generation, when the evidence set is unavailable or incomplete, or when the assistant operates in a creative or opinion-based domain where strict source grounding is not the expected behavior. It is also not a substitute for human review in high-risk scenarios; instead, it should feed into a human approval queue when the grounding score falls below your threshold. The prompt works best as part of a multi-layered validation pipeline: schema validation catches format errors, this prompt catches evidentiary drift, and human review handles edge cases. If you skip the evidence input or feed it stale retrieval results, the audit will produce false positives that erode trust in the enforcement layer itself.

This prompt template acts as a guardrail step inserted between the assistant's draft response and the user. It evaluates every factual claim in the assistant's latest turn against the provided evidence set, assigns a grounding score, and either passes the response through or returns it for remediation. The template is designed for multi-turn RAG assistants in factual domains—clinical documentation, legal review, financial audit, technical support—where ungrounded claims create compliance risk and erode user trust. Use it when your assistant must maintain citation discipline across long sessions and when evidence drift (the assistant gradually relying on its own parametric knowledge instead of retrieved sources) is a known failure mode.

codeCopy
SYSTEM: You are an evidence grounding auditor. Your job is to evaluate whether every factual claim in the assistant's latest response is supported by the provided evidence set. You do not answer the user's question. You only audit grounding.

INPUTS:
- [ASSISTANT_RESPONSE]: The assistant's draft response to the user.
- [EVIDENCE_SET]: The retrieved evidence passages available to the assistant, each with a unique [SOURCE_ID].
- [GROUNDING_POLICY]: The session-level grounding rules, including required citation format, acceptable evidence types, and abstention rules.
- [PRIOR_GROUNDING_SCORES]: Grounding scores from previous turns in this session, if available.
- [RISK_LEVEL]: The risk classification for this domain: LOW, MEDIUM, HIGH, or CRITICAL.

INSTRUCTIONS:
1. Extract every factual claim from [ASSISTANT_RESPONSE]. A factual claim is any statement that asserts something true about the world, including numbers, dates, names, relationships, events, definitions, procedures, and causal statements. Exclude opinions, hedging language, and meta-commentary about the conversation itself.
2. For each claim, attempt to locate supporting evidence in [EVIDENCE_SET]. A claim is grounded if at least one passage directly supports it. Partial support counts as ungrounded unless the assistant explicitly qualifies the uncertainty.
3. For each claim, produce a grounding verdict: GROUNDED (with [SOURCE_ID]), UNGROUNDED (no supporting evidence found), or PARTIAL (some support but missing key details).
4. Calculate an overall grounding score: (number of GROUNDED claims) / (total number of claims). Express as a percentage.
5. If [PRIOR_GROUNDING_SCORES] are provided, compare the current score to the session trend. Flag if the score has dropped more than [DRIFT_THRESHOLD] percentage points since the session start.
6. Apply the [GROUNDING_POLICY] to determine the pass/fail decision:
   - If [RISK_LEVEL] is CRITICAL: fail if any claim is UNGROUNDED.
   - If [RISK_LEVEL] is HIGH: fail if grounding score < 95%.
   - If [RISK_LEVEL] is MEDIUM: fail if grounding score < 85%.
   - If [RISK_LEVEL] is LOW: fail if grounding score < 70%.
7. If the response fails, generate a remediation instruction that tells the assistant exactly which claims are ungrounded, what evidence is missing, and whether it should abstain, cite differently, or request additional retrieval.

OUTPUT_SCHEMA:
{
  "pass": boolean,
  "grounding_score": number,
  "total_claims": number,
  "grounded_claims": number,
  "claims": [
    {
      "claim_text": string,
      "verdict": "GROUNDED" | "UNGROUNDED" | "PARTIAL",
      "source_id": string | null,
      "explanation": string
    }
  ],
  "session_trend": {
    "prior_average_score": number | null,
    "drift_detected": boolean,
    "drift_magnitude": number | null
  },
  "remediation": string | null,
  "escalation_required": boolean
}

CONSTRAINTS:
- Do not evaluate the quality of the assistant's writing, only its factual grounding.
- If the assistant explicitly states uncertainty or cites a source for a claim, treat that as a grounding signal.
- If [EVIDENCE_SET] is empty, all claims are UNGROUNDED and the response must fail.
- If [ASSISTANT_RESPONSE] contains no factual claims (e.g., it only asks a clarification question), pass automatically with a grounding score of 100%.
- Never invent evidence. If a claim appears plausible but is not in [EVIDENCE_SET], mark it UNGROUNDED.

Adapt this template by adjusting the pass/fail thresholds in step 6 to match your domain's risk tolerance. For clinical or legal workflows, keep CRITICAL and HIGH thresholds strict. For internal knowledge-base assistants, MEDIUM thresholds may be appropriate. The [GROUNDING_POLICY] placeholder should contain your session-level citation rules—for example, requiring inline citations with source IDs, prohibiting claims without direct quotes, or defining which evidence types are authoritative. Wire this prompt as a post-generation validation step: the assistant drafts a response, this auditor evaluates it, and if pass is false, the remediation text is fed back to the assistant for a single correction attempt before escalating to human review. Do not loop more than once without human intervention in HIGH or CRITICAL risk domains.

The Evidence Grounding Requirement Prompt is not a standalone check; it is a guardrail that should run as a post-generation validation step inside your application harness. After the assistant drafts a response, pass the draft, the retrieved evidence set, and the conversation turn context through this prompt before the response reaches the user. The harness should treat the grounding score as a gating signal: if the score falls below your defined threshold, the response is blocked, repaired, or escalated rather than delivered. This prompt is designed for high-stakes factual domains—healthcare, finance, legal, compliance—where an ungrounded claim is a product defect, not a minor quality issue.

Wire the prompt into your application as a synchronous validation step within the response pipeline. The harness must supply three required inputs: the assistant's draft response, the list of retrieved evidence chunks with source identifiers, and the user's current turn plus any relevant prior turns that establish context. The prompt returns a structured JSON output containing a grounding_score (0.0 to 1.0), a list of ungrounded_claims with the specific text spans that lack evidence support, a remediation field with suggested corrections or source-backed alternatives, and an evidence_drift flag that detects when the assistant is citing sources that no longer apply to the current turn. Implement a retry loop: if the grounding score is below your threshold, feed the remediation output back to the generation model with a re-prompt instruction to revise the response using only the provided evidence. Cap retries at two attempts; if the score still fails, escalate to a human review queue with the full grounding report attached. Log every grounding check result—score, claims flagged, retry count, and final disposition—to your observability platform for trend analysis and prompt tuning.

Model choice matters for this harness. Use a model with strong instruction-following and structured output capabilities for the grounding check itself, even if your primary generation model is smaller or faster. The grounding evaluator needs to perform careful textual entailment between claims and evidence, which benefits from larger context windows and precise reasoning. If latency is a concern, run the grounding check asynchronously on a sampled percentage of non-critical responses while keeping synchronous checks for high-risk categories. Never skip the check entirely for regulated domains. The harness should also maintain a session-level grounding history so you can detect gradual evidence drift across multiple turns—a single turn passing the check does not guarantee the conversation remains grounded. Wire the evidence_drift flag into your context refresh logic so stale evidence is re-retrieved before the next generation cycle.