This prompt is built for RAG evaluation teams who need to verify that every reasoning step in a chain-of-thought trace is properly supported by the cited evidence. It acts as an automated judge that scores citation accuracy, flags misattributions, and detects quote-context mismatches. Use this when you are shipping a reasoning system where the path matters as much as the final answer, and you cannot afford hallucinations disguised as evidence-backed logic. The ideal user is an AI engineer or evaluation lead who already has a reasoning trace with explicit citations and the corresponding source documents available for cross-referencing.
Prompt
Evidence Citation Accuracy in CoT Prompt

When to Use This Prompt
Defines the job-to-be-done, ideal user, required context, and critical limitations for deploying the Evidence Citation Accuracy in CoT evaluation prompt.
This prompt belongs in your evaluation pipeline, not in your user-facing generation flow. It assumes you have already extracted a reasoning trace from your system—complete with step-by-step logic and explicit references to source passages—and that you have the full text of those source documents available. The prompt will produce a structured scorecard that includes per-step citation accuracy labels, misattribution flags, and quote-context mismatch detection. You should wire this into a batch evaluation harness that runs after each reasoning trace is generated, logging results for trend analysis and regression detection.
Do not use this prompt when you lack access to the original source documents, when the reasoning trace does not include explicit citations, or when you need a single holistic score without step-level granularity. It is also inappropriate for evaluating creative writing, subjective analysis, or tasks where evidence support is not the primary quality dimension. If your system generates answers without showing its work, start with a groundedness or faithfulness evaluation prompt instead. For high-stakes domains like healthcare or legal review, always pair this automated judge with human spot-checking and maintain an audit trail of judge decisions.
Use Case Fit
Where the Evidence Citation Accuracy prompt delivers reliable results and where it introduces operational risk.
Strong Fit: RAG Systems with Explicit Source Mapping
Use when: your retrieval pipeline returns distinct source chunks with stable IDs, and each reasoning step should reference a specific chunk. Guardrail: require the prompt to output source_id and quote_snippet for every citation so mismatches are programmatically detectable.
Strong Fit: Pre-Release Regression Gates
Use when: you have a golden dataset of reasoning traces with known-correct citations and need automated pass/fail checks before shipping a prompt change. Guardrail: pair citation accuracy scores with a minimum threshold and block the release if the score regresses.
Poor Fit: Implicit Knowledge Tasks
Avoid when: the model is expected to reason from its own parametric knowledge without grounding in provided evidence. Guardrail: if no source chunks are supplied, skip citation accuracy evaluation entirely and switch to a factual-grounding or hallucination check instead.
Poor Fit: Creative or Subjective Reasoning
Avoid when: the reasoning trace involves opinion, interpretation, or stylistic judgment where evidence support is inherently ambiguous. Guardrail: use pairwise human preference evaluation for subjective tasks and reserve citation accuracy for verifiable factual claims.
Required Input: Source Chunks with Stable Identifiers
Risk: without stable source IDs, the evaluator cannot reliably match citations to evidence, producing false misattribution flags. Guardrail: ensure your retrieval pipeline attaches a unique chunk_id to every passage and include it in the prompt context alongside the text.
Operational Risk: Quote-Context Mismatch Blind Spots
Risk: a citation may contain a verbatim quote from the source but still misrepresent the source's intended meaning by stripping surrounding context. Guardrail: add a secondary check that compares the cited quote against a wider context window from the same source chunk to detect semantic distortion.
Copy-Ready Prompt Template
A reusable prompt for evaluating whether cited evidence in a reasoning trace actually supports the step that references it.
This prompt template is the core evaluation instruction for grading evidence citation accuracy in chain-of-thought outputs. It is designed for RAG evaluation teams who need to verify that every citation in a reasoning trace points to source material that genuinely supports the claim being made. The prompt produces structured scores, misattribution flags, and quote-context mismatch detection, making it suitable for automated evaluation pipelines where citation fidelity is a release gate. Copy this template into your evaluation harness and replace the square-bracket placeholders before each run.
textYou are an evidence citation auditor evaluating a reasoning trace. Your job is to verify that every cited piece of evidence actually supports the reasoning step that references it. Do not evaluate whether the final answer is correct. Only evaluate citation accuracy. ## INPUT **Reasoning Trace:** [REASONING_TRACE] **Source Documents (with citation IDs):** [SOURCE_DOCUMENTS] ## EVALUATION INSTRUCTIONS For each citation reference in the reasoning trace, perform the following checks: 1. **Citation Existence:** Does the cited source ID exist in the provided source documents? If not, flag as `citation_not_found`. 2. **Quote Accuracy:** If the reasoning step quotes or paraphrases the source, does the quoted material actually appear in the cited source? Flag any fabricated or distorted quotes as `quote_mismatch`. 3. **Context Fidelity:** Does the cited passage, when read in its full context, support the claim made in the reasoning step? Flag cases where the citation is taken out of context or contradicts the claim as `context_mismatch`. 4. **Claim Support Strength:** Rate how strongly the cited evidence supports the reasoning step's claim on this scale: - `fully_supported`: The evidence directly and unambiguously supports the claim. - `partially_supported`: The evidence provides some support but requires inference or additional assumptions. - `unsupported`: The evidence does not support the claim or contradicts it. ## OUTPUT SCHEMA Return a JSON object with this exact structure: { "overall_citation_accuracy_score": <float between 0.0 and 1.0>, "total_citations_evaluated": <integer>, "citation_evaluations": [ { "citation_id": "<string>", "reasoning_step_index": <integer>, "reasoning_step_text": "<excerpt from reasoning trace>", "citation_exists": <boolean>, "quote_accurate": <boolean>, "context_fidelity": "<accurate | mismatch | partial_mismatch>", "claim_support_strength": "<fully_supported | partially_supported | unsupported>", "explanation": "<brief explanation of the evaluation>", "flagged": <boolean> } ], "misattribution_flags": [ { "citation_id": "<string>", "flag_type": "<citation_not_found | quote_mismatch | context_mismatch | unsupported>", "severity": "<critical | major | minor>", "detail": "<description of the problem>" } ], "summary": "<one-paragraph summary of citation accuracy findings>" } ## SCORING RULES - `overall_citation_accuracy_score` = (number of citations with `claim_support_strength` of `fully_supported` or `partially_supported` AND no flags) / `total_citations_evaluated` - A citation with any flag (`citation_not_found`, `quote_mismatch`, `context_mismatch`) automatically counts as inaccurate for the overall score. - `partially_supported` citations without flags count as 0.5 toward the score numerator. - `fully_supported` citations without flags count as 1.0 toward the score numerator. ## CONSTRAINTS - Only evaluate citations that appear in the reasoning trace. Do not invent citations to check. - If the reasoning trace makes claims without citations, note this in the summary but do not penalize the citation accuracy score. - Do not evaluate the quality of the reasoning itself, only the accuracy of evidence citations. - If a source document is ambiguous, note the ambiguity in your explanation and score conservatively. - [ADDITIONAL_CONSTRAINTS] ## EXAMPLES [FEW_SHOT_EXAMPLES]
After copying the template, replace the placeholders with your actual data. [REASONING_TRACE] should contain the full chain-of-thought output you are evaluating, with citation markers preserved. [SOURCE_DOCUMENTS] must include the complete text of every retrievable source, each labeled with the same citation IDs used in the reasoning trace. Use [ADDITIONAL_CONSTRAINTS] to inject domain-specific rules, such as requiring exact quote matching for regulated industries or adjusting the partial-support threshold. [FEW_SHOT_EXAMPLES] is critical for calibration: include at least two examples showing correct citation evaluation and one showing a misattribution flag. Without examples, the model may conflate reasoning quality with citation accuracy or miss subtle context mismatches. Before running this in production, validate the output JSON against the schema and confirm that every citation in the reasoning trace appears in the evaluation output. Missing citations in the evaluation indicate the model skipped a check, which is a silent failure mode.
Prompt Variables
Required inputs for the Evidence Citation Accuracy in CoT Prompt. Each variable must be populated before the prompt is assembled and sent. Missing or malformed inputs are the most common cause of low citation accuracy scores.
| Placeholder | Purpose | Example | Validation Notes |
|---|---|---|---|
[REASONING_TRACE] | The full chain-of-thought output to evaluate, including all reasoning steps and inline citations | Step 1: The patient presents with fever [DocA-p3]. Step 2: Fever indicates possible infection [DocB-p12]. Therefore, antibiotics are indicated. | Must contain at least one citation marker. Parse check: confirm presence of bracket-delimited source references. Null not allowed. |
[SOURCE_DOCUMENTS] | The complete set of source documents or passages that the reasoning trace cites, with unique identifiers | DocA: Clinical guidelines for fever management. DocB: Antibiotic stewardship protocol v2. DocC: Patient history summary. | Each document must have a unique ID matching citation markers in the trace. Schema check: map of doc_id to full text. Empty collection triggers abstention. |
[CITATION_FORMAT] | The expected citation pattern used in the reasoning trace, specified as a regex or format description | [DocID-section] or [SourceName-pParagraphNumber] | Must be parseable as a regex or unambiguous format string. Mismatch between declared format and actual citations produces false negatives. Default: bracket-delimited source-page pattern. |
[OUTPUT_SCHEMA] | The exact JSON schema for the evaluation output, defining fields for per-step scores, misattribution flags, and mismatch details | {"steps": [{"step_index": int, "citation": string, "accuracy": "supported|partial|unsupported", "evidence_quote": string, "mismatch_detail": string|null}], "overall_score": float} | Schema must include step_index, accuracy enum, and evidence_quote fields at minimum. Validate with JSON Schema before sending. Missing required fields cause downstream parse failures. |
[ACCURACY_THRESHOLD] | The minimum citation accuracy score required for the trace to pass, expressed as a float between 0.0 and 1.0 | 0.85 | Must be a float in range [0.0, 1.0]. Values outside range trigger a validation error. Used to gate pass/fail decisions in automated pipelines. Default: 0.80 if not specified. |
[MISATTRIBUTION_SEVERITY] | The severity weighting for different types of citation failures, used to calibrate the overall score | {"fabricated_citation": 1.0, "quote_context_mismatch": 0.8, "partial_support": 0.4, "correct": 0.0} | Must be a valid JSON object with keys matching failure types. Missing keys default to 0.5 severity. Schema check required before scoring. Incorrect weights skew overall accuracy scores. |
[CONTEXT_WINDOW_SIZE] | The number of characters before and after a cited passage to include when verifying quote-context alignment | 300 | Must be a positive integer. Too small misses context needed for mismatch detection. Too large introduces noise and increases token cost. Recommended range: 200-500. Default: 300. |
[ABSTENTION_RULES] | Conditions under which the evaluator should abstain from scoring a citation rather than guessing, specified as a list of triggers | ["source_document_missing", "ambiguous_citation_marker", "non_retrievable_reference"] | Must be a JSON array of valid abstention trigger strings. Empty array means never abstain. Each trigger must map to a handler in the evaluation harness. Abstention without a handler causes null scores. |
Implementation Harness Notes
How to wire the Evidence Citation Accuracy prompt into a production RAG evaluation pipeline with validation, retries, and human review gates.
The Evidence Citation Accuracy prompt is designed to operate as a post-hoc evaluation step in a RAG pipeline, not as a real-time guardrail. After a reasoning trace is generated, this prompt should be called asynchronously to score each citation against its source evidence. The harness must pass the full reasoning trace, the list of cited evidence chunks with their unique identifiers, and the original source documents. The model returns a structured JSON object containing per-citation accuracy scores, misattribution flags, and quote-context mismatch descriptions. This output should be logged alongside the original trace for auditability and used to gate whether the reasoning output is surfaced to users or routed for human review.
Wire the prompt into an evaluation service that runs after the primary reasoning model returns. The service should: (1) extract all citation references from the reasoning trace using a regex or parser that matches your citation format (e.g., [1], [doc_3]); (2) retrieve the corresponding evidence chunks from your vector store or document store using the citation IDs; (3) assemble the prompt with the reasoning trace, the evidence chunks, and the source documents; (4) call a model with strong instruction-following and structured output capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent); (5) parse the JSON response and validate that every cited reference in the trace received a score. If the model returns malformed JSON, implement a single retry with the error message appended to the prompt. If the retry also fails, flag the entire trace for human review and log the raw response. For high-stakes domains like healthcare or legal, set a threshold—any citation with an accuracy score below 0.8 or any misattribution flag set to true should automatically escalate the output to a human reviewer before it reaches the end user.
Model choice matters here. Use a model with a large context window (128k tokens or more) to accommodate long reasoning traces with many citations. Avoid models that struggle with fine-grained text comparison, as the core task requires precise alignment between a reasoning step and a specific passage. If your RAG system uses chunked evidence, ensure each chunk passed to the evaluator includes enough surrounding context to resolve anaphora and implicit references. Log every evaluation result with the trace ID, timestamp, model version, and scores. This log becomes your audit trail for citation accuracy over time and feeds into regression tests when you change your retrieval or reasoning prompts. Do not use this prompt to block outputs in latency-sensitive user-facing flows; it is an evaluation and gating tool, not a streaming guardrail.
Expected Output Contract
Defines the required fields, types, and validation rules for the JSON object produced by the Evidence Citation Accuracy in CoT prompt. Use this contract to parse, validate, and integrate the output into downstream evaluation pipelines.
| Field or Element | Type or Format | Required | Validation Rule |
|---|---|---|---|
citation_accuracy_score | float (0.0 to 1.0) | Must be a number between 0 and 1 inclusive. Parse as float and check bounds. | |
reasoning_steps | array of objects | Must be a non-empty array. Schema check: each element must be an object. | |
reasoning_steps[].step_index | integer | Must be a non-negative integer. Validate sequential ordering and no duplicates across the array. | |
reasoning_steps[].step_text | string | Must be a non-empty string. Should match a discrete reasoning step from the input [COT_TRACE]. | |
reasoning_steps[].cited_evidence | array of strings | Must be an array. Each string should be a verbatim quote from the provided [EVIDENCE_SET]. Perform exact or fuzzy substring match. | |
reasoning_steps[].citation_verdict | string enum | Must be one of: 'SUPPORTED', 'MISATTRIBUTED', 'UNSUPPORTED'. Validate against the allowed enum set. | |
reasoning_steps[].mismatch_detail | string or null | If citation_verdict is 'MISATTRIBUTED' or 'UNSUPPORTED', this must be a non-empty string explaining the gap. If 'SUPPORTED', this must be null. | |
overall_assessment | string | If present, must be a non-empty string summarizing key failure patterns. Null allowed. |
Common Failure Modes
Evidence citation accuracy in Chain-of-Thought prompts breaks in predictable ways. These are the most common failure modes when verifying that cited evidence actually supports the reasoning step that references it, with practical mitigations for each.
Quote-Context Mismatch
What to watch: The model cites a passage that exists in the source but the quoted text doesn't support the reasoning step it's attached to. The citation is real, the quote is accurate, but the logical connection is fabricated. Guardrail: Add a verification sub-step that requires the model to restate what the cited passage actually claims before using it as evidence. Run a secondary groundedness check comparing the reasoning step's claim against the raw cited text.
Fabricated Citations
What to watch: The model generates plausible-looking citations with document names, section numbers, or line references that don't exist in the source material. This is especially common with long documents where the model hallucinates structure. Guardrail: Pre-extract all citable segments with unique IDs before the reasoning step. Require the model to reference only pre-assigned IDs. Post-validate every citation ID against the source index and reject outputs with unmatched references.
Cherry-Picked Evidence
What to watch: The model selects only evidence that supports its conclusion while ignoring contradictory passages in the same source. The citations are real but the reasoning is biased by omission. Guardrail: Add a counter-evidence check step that explicitly asks: 'What passages in the provided sources contradict or weaken this reasoning?' Require the model to acknowledge and address conflicting evidence before finalizing the reasoning trace.
Stale or Out-of-Scope Citations
What to watch: The model cites evidence from the correct source but references a section that's irrelevant to the current reasoning step—often from a different topic, time period, or context within the same document. Guardrail: Include scope constraints in the citation instruction: 'Only cite passages that directly address [SPECIFIC_CLAIM].' Use a relevance validator that checks semantic similarity between the reasoning step and the cited passage, flagging low-alignment pairs.
Citation Proximity Collapse
What to watch: In long reasoning traces, later steps drift from their citations. The model correctly cites evidence for step 1, but by step 4 it's still pointing to the same passage even though the reasoning has moved to a different claim. Guardrail: Require per-step citation refresh: each reasoning step must independently cite its supporting evidence. Add a cross-step citation diversity check that flags when the same citation is reused across semantically distinct reasoning steps without justification.
Overclaimed Citation Strength
What to watch: The model cites a passage that partially supports the reasoning but presents it as definitive proof. The evidence is real but the certainty level is inflated—a hedging passage gets cited as conclusive. Guardrail: Add an evidence-strength calibration instruction: 'Label each citation with the strength of support it provides: direct proof, partial support, weak alignment, or background context.' Flag reasoning steps that claim certainty from weak or partial evidence.
Evaluation Rubric
Use this rubric to test whether a CoT prompt's citations are accurate. Each criterion targets a specific failure mode in evidence-to-reasoning alignment. Run these checks on a sample of outputs before shipping the prompt to production.
| Criterion | Pass Standard | Failure Signal | Test Method |
|---|---|---|---|
Quote-Context Match | Every quoted string in a reasoning step appears verbatim in the cited [SOURCE_DOCUMENT]. | A quoted string in the reasoning step cannot be found in the cited source, or the quote is altered. | LLM-as-judge with substring matching: extract all quoted strings from the reasoning step, search for each in the cited source text, flag any missing matches. |
Claim-Source Alignment | Every factual claim in a reasoning step is directly supported by the cited [SOURCE_DOCUMENT] passage. | A reasoning step makes a factual assertion that contradicts the cited source, or the source is silent on the claim. | LLM-as-judge pairwise check: for each reasoning step, present the claim and the cited passage to a judge model, ask 'Does this passage support this claim? (yes/no)'. |
Misattribution Flagging | No reasoning step cites [SOURCE_A] when the evidence actually comes from [SOURCE_B]. | A citation label points to the wrong source document or passage. | Cross-reference test: for each citation marker in the reasoning trace, verify the referenced content exists in the named source. Flag any citation where the content is found in a different source instead. |
Fabricated Citation Detection | Every citation marker references a real, retrievable source passage provided in the [CONTEXT]. | A citation marker references a source ID, page number, or passage that does not exist in the provided context. | Schema validation: extract all citation IDs from the output, check each against the set of valid source IDs in the input context. Flag any ID not present. |
Out-of-Context Evidence Use | Cited evidence is used in a way consistent with its original context and meaning in [SOURCE_DOCUMENT]. | A passage is cited to support a claim that reverses, distorts, or cherry-picks the passage's original meaning. | LLM-as-judge context check: present the full surrounding paragraph from the source alongside the reasoning step's use of it, ask 'Is the passage used in a way consistent with its original meaning? (yes/no)'. |
Citation Completeness | Every reasoning step that makes a factual claim includes at least one citation to supporting evidence. | A reasoning step asserts a specific fact, statistic, or external claim without any citation marker. | Regex scan: for each reasoning step, check for presence of citation markers. Flag any step containing factual assertions but zero citations. |
Evidence Relevance Scoring | Cited passages are topically relevant to the reasoning step they support, with relevance score above [RELEVANCE_THRESHOLD]. | A cited passage is tangentially related or unrelated to the reasoning step's claim. | LLM-as-judge relevance rating: for each citation-step pair, ask 'On a scale of 1-5, how relevant is this passage to the reasoning step's claim?' Flag scores below the threshold. |
Multi-Source Conflict Resolution | When multiple sources are cited, the reasoning step acknowledges and resolves any contradictions between them. | Conflicting evidence from different sources is cited without noting the conflict or explaining the resolution. | LLM-as-judge conflict check: when a step cites multiple sources, present all cited passages to a judge model, ask 'Do these passages conflict? If yes, does the reasoning step acknowledge the conflict?' |
Enabling Efficiency, Speed & Accuracy
Intelligent Analysis, Decision & Execution
We build AI systems for teams that need search across company data, workflow automation across tools, or AI features inside products and internal software.
Talk to Us
Search across company data
Give teams answers from docs, tickets, runbooks, and product data with sources and permissions.
Useful when people spend too long searching or get different answers from different systems.

Automate internal workflows
Use AI to route work, draft outputs, trigger actions, and keep approvals and logs in place.
Useful when repetitive work moves across multiple tools and teams.

Add AI to products and internal tools
Build assistants, guided actions, or decision support into the software your team or customers already use.
Useful when AI needs to be part of the product, not a separate tool.
Adapt This Prompt
How to adapt
Add structured output enforcement with a strict JSON schema. Require per-step citation objects with fields: step_index, citation_text, source_passage_id, support_level (enum: direct, partial, none, contradicts), quote_match_exact (boolean), and context_mismatch_flag (boolean).
Implement a two-pass evaluation: first pass flags all citation issues, second pass re-evaluates flagged steps with the full source context expanded. Add retry logic with exponential backoff for malformed outputs. Log every evaluation with trace IDs for observability.
Wire in eval assertions: citation_support_rate >= 0.95, false_positive_rate < 0.05, inter_judge_agreement >= 0.90 against a golden dataset of 200+ annotated traces.
Watch for
- Silent format drift where the model drops optional fields under high load
- Context window overflow when expanding source passages for re-evaluation
- Judge fatigue on long reasoning traces—citation accuracy degrades after step 15-20
- Missing human review for
contradictsflags before surfacing to end users

About the author
Prasad Kumkar
CEO & MD, Inference Systems
Prasad Kumkar is the CEO & MD of Inference Systems and writes about AI systems architecture, LLM infrastructure, model serving, evaluation, and production deployment. Over 5+ years, he has worked across computer vision models, L5 autonomous vehicle systems, and LLM research, with a focus on taking complex AI ideas into real-world engineering systems.
His work and writing cover AI systems, large language models, AI agents, multimodal systems, autonomous systems, inference optimization, RAG, evaluation, and production AI engineering.
Partnered with leading AI, data, and software stack.
How We Work
Custom AI workflows for your Business
One-fit-all AI don't work for modern businesses. At Inferensys, we aim to understand your business & custom requirements; which we use to define most efficient agentic workflows, the data, and the tools for your business.
01
Review the use case
We understand the task, the users, and where AI can actually help.
Read more02
Pick the right approach
We define what needs search, automation, or product integration.
Read more03
Build the first useful version
We implement the part that proves the value first.
Read more04
Improve from there
We add the checks and visibility needed to keep it useful.
Read moreThe first call is a practical review of your use case and the right next step.
Talk to Us