Reasoning Chain Audit Prompt for Faithfulness Checks

This prompt is designed for quality assurance engineers and AI safety operators who need to verify that a generated reasoning chain is strictly faithful to the provided source evidence. The core job-to-be-done is a post-hoc audit: you have a final answer and the step-by-step reasoning the model claims to have used, and you must confirm that every inferential leap, factual claim, and citation is directly supported by the source documents. This is not a prompt for generating answers; it is a guardrail for catching hallucinations, misattributed citations, and unsupported extrapolations before an answer reaches a user or a downstream system.

Use this prompt when the cost of an incorrect or fabricated answer is high—such as in clinical, legal, financial, or compliance workflows. It is most effective when you can provide a complete reasoning chain (e.g., from a Chain-of-Thought or multi-hop RAG pipeline) alongside the full set of retrieved source chunks. The prompt requires the auditor to have access to the original evidence, not just the model's summary of it. Do not use this prompt for real-time, low-latency chat where a full audit would block the user experience, or when the reasoning chain is implicit and cannot be extracted as discrete, auditable steps. It is also unsuitable for purely creative or subjective tasks where 'faithfulness' has no objective ground truth.

Before integrating this prompt into your harness, ensure your pipeline can capture and pass the raw reasoning trace and the exact source documents used. The output is an audit report, not a corrected answer. If the audit flags failures, your system should be designed to either regenerate the answer, escalate for human review, or abstain. Start by running this prompt against a golden dataset of known faithful and hallucinated reasoning chains to calibrate your pass/fail thresholds before deploying it as a production guardrail.

This prompt template is designed for post-hoc auditing of a generated reasoning chain. It takes the original question, the source evidence, and the reasoning chain as input, then produces a structured audit report. The report flags unsupported inferential leaps, hallucinations, misattributed citations, and logical gaps. Use this template as a safety gate in high-stakes domains like legal, clinical, or financial Q&A where a wrong answer is worse than no answer. The template is model-agnostic and expects square-bracket placeholders to be filled by your application harness before inference.

textCopy
You are a reasoning chain auditor. Your job is to verify that every step in a reasoning chain is fully supported by the provided source evidence. You do not judge whether the final answer is correct. You judge whether the reasoning itself is faithful to the sources.

## INPUT

**Original Question:**
[QUESTION]

**Source Evidence (numbered):**
[EVIDENCE_LIST]

**Reasoning Chain to Audit:**
[REASONING_CHAIN]

## AUDIT INSTRUCTIONS

For each step in the reasoning chain:
1. Identify the specific factual claim or inferential leap made in that step.
2. Check whether that claim is directly supported by one or more pieces of source evidence. Cite the evidence number(s).
3. If the claim is not supported, classify it as one of:
   - **UNSUPPORTED_LEAP**: The step draws a conclusion not present in the evidence.
   - **HALLUCINATION**: The step introduces a fact not found in any source.
   - **MISATTRIBUTION**: The step cites a source that does not contain the claimed information.
   - **MISSING_EVIDENCE**: The step requires evidence that is not provided.
4. If the step is supported, mark it as **GROUNDED** and provide the supporting citation.

## OUTPUT FORMAT

Return a JSON object with this exact schema:
{
  "audit_result": "PASS" | "FAIL" | "PARTIAL",
  "overall_assessment": "A one-sentence summary of the audit findings.",
  "steps": [
    {
      "step_number": 1,
      "step_text": "The text of the reasoning step.",
      "verdict": "GROUNDED" | "UNSUPPORTED_LEAP" | "HALLUCINATION" | "MISATTRIBUTION" | "MISSING_EVIDENCE",
      "evidence_citation": [1, 3] or [],
      "explanation": "Why this verdict was reached."
    }
  ],
  "critical_flags": [
    "Description of any finding that makes the entire chain unreliable."
  ]
}

## CONSTRAINTS

- Do not evaluate whether the final answer is correct. Only evaluate whether the reasoning chain is faithful to the provided evidence.
- If a step combines multiple pieces of evidence, verify each sub-claim independently.
- If the reasoning chain contains a step that is a question or a plan rather than a claim, mark it as **GROUNDED** only if the question or plan logically follows from prior grounded steps.
- If the evidence is insufficient to support or refute a step, mark it as **MISSING_EVIDENCE**.
- Be strict. When in doubt, flag rather than assume support.

To adapt this template, replace the placeholders with your application data. [QUESTION] should contain the original user query. [EVIDENCE_LIST] should be a numbered list of retrieved passages, each with a unique identifier. [REASONING_CHAIN] should be the full text of the reasoning chain you want to audit, including any internal citations it contains. The output schema is strict JSON, so your harness should validate the response against the schema before accepting it. For high-risk domains, route any audit with a FAIL or PARTIAL result to human review. Consider running this audit prompt with a different model than the one that generated the reasoning chain to reduce correlated failures.

The Reasoning Chain Audit Prompt is not a user-facing prompt. It operates as a post-generation guardrail inside a QA harness. After your primary RAG system produces a reasoning chain and final answer, the audit prompt receives the original question, the retrieved source evidence, and the generated reasoning chain as input. Its job is to produce a structured audit report that flags unsupported inferential leaps, hallucinated facts, and misattributed citations before the answer reaches a user or downstream system. This means the audit prompt must be wired into a pipeline that can act on its output—blocking, flagging for review, or triggering regeneration—rather than simply displaying the report.

Wire the audit prompt as a synchronous validation step after reasoning chain generation and before answer delivery. The harness should: (1) extract the reasoning chain from the primary model's output, (2) call the audit prompt with the original question, the full set of retrieved source chunks (with document IDs and chunk indices), and the reasoning chain, (3) parse the audit report JSON to extract the overall_verdict (pass/fail) and any flagged steps, (4) if the verdict is fail, either block the response and escalate for human review or trigger a regeneration loop with explicit feedback about which steps were unsupported. For high-stakes domains like clinical or legal RAG, always route fail verdicts to a human review queue. For lower-stakes applications, you may allow up to two regeneration attempts with the audit feedback injected as a correction signal before escalating.

Model choice matters here. The audit prompt requires strong instruction-following and careful attention to detail. Use a capable model like Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro. Avoid smaller or faster models that may miss subtle unsupported inferences. Implement a strict JSON schema validator on the audit output—if the model fails to produce valid JSON matching the expected schema, retry once with a schema error message. Log every audit result, including passed audits, to build a dataset for evaluating your primary reasoning prompt over time. This log becomes your regression test suite: when you change the reasoning prompt, re-run the audit on historical cases to detect new hallucination patterns. Finally, set a latency budget. The audit adds a second model call, so if your primary generation takes 2 seconds, expect total latency of 3-5 seconds. For real-time applications, consider running the audit asynchronously and delivering the answer with a provisional flag, then updating or retracting if the audit later fails.