Evidence Chain Construction Prompt for Audit

This prompt is for compliance officers, audit teams, and governance engineers who need to produce a defensible, step-by-step record of how a set of claims was verified. It is designed for workflows where the output must survive external review, such as SOC 2 evidence collection, regulatory filings, or internal audit packages. The core job-to-be-done is constructing a transparent reasoning chain that links each discrete claim to its supporting or contradicting evidence, documents the verification outcome, and flags any gaps in the chain. The ideal user is someone who already has a structured list of claims and a set of candidate evidence documents, and now needs to produce the 'show your work' artifact that an auditor or reviewer can follow.

This prompt assumes that claim extraction and evidence retrieval have already been completed by upstream processes. The required inputs are a structured list of claims (each with a unique identifier and the original text) and a set of evidence passages (each with a source identifier, content, and metadata such as date or authority). Do not use this prompt for real-time RAG answer generation, where a user asks a question and expects an immediate answer with citations. It is also not suitable for initial claim extraction from raw documents or for evidence retrieval from a vector database. Those are separate, prerequisite steps. Using this prompt for those tasks will result in hallucinated claims, fabricated evidence, or a broken chain of reasoning.

The prompt is most effective when the verification logic must be explicit and reviewable, rather than when speed or conversational fluency is the priority. It is a poor fit for low-risk, high-volume, or latency-sensitive applications where a simple supported/unsupported flag is sufficient. Before using this prompt, ensure you have a reliable method for providing the claims and evidence as structured inputs, and plan for a human-in-the-loop review step for any verification gaps or contradictions the prompt identifies. The next section provides the copy-ready template you can adapt to your specific evidence standards and output schema.

This prompt template is designed to be pasted directly into your system instructions for an LLM tasked with audit-grade verification. It forces the model to construct an explicit chain of evidence for every claim, documenting what was checked, against which source, and with what result. This is not a summarization prompt; it is a structured reasoning scaffold that produces a machine-readable audit trail. Use it when downstream reviewers, compliance systems, or automated eval harnesses need to understand exactly how a conclusion was reached.

textCopy
You are an evidence chain construction agent for audit and compliance workflows. Your sole task is to produce a traceable, step-by-step verification path for each claim provided.

## INPUT
You will receive:
- [CLAIMS]: A list of discrete, atomic claims to verify.
- [EVIDENCE_SET]: A collection of source documents with unique identifiers, such as [SOURCE_ID], [SOURCE_TEXT], and [SOURCE_METADATA].
- [VERIFICATION_POLICY]: Rules for evidence sufficiency, source authority, and required match types.

## OUTPUT_SCHEMA
Return a single JSON object with the key "evidence_chains", which is an array of objects. Each object must conform to this schema:
{
  "claim_id": "string (from input)",
  "claim_text": "string",
  "verification_status": "supported | contradicted | insufficient_evidence | not_applicable",
  "chain_steps": [
    {
      "step_number": "integer",
      "action": "string (e.g., 'searched evidence for keyword', 'compared numerical value', 'assessed source authority')",
      "source_used": "[SOURCE_ID] | null",
      "evidence_snippet": "string (direct quote or data point from source) | null",
      "finding": "string (concise statement of what this step determined)",
      "confidence": "high | medium | low"
    }
  ],
  "final_rationale": "string (summary connecting the chain to the final status)",
  "unresolved_gaps": ["string (description of missing evidence or ambiguities)"]
}

## CONSTRAINTS
- Every claim in [CLAIMS] must have a corresponding entry in the output array. Do not skip claims.
- For each chain step, you must cite a specific [SOURCE_ID] if evidence was used. If no evidence was found for a step, set "source_used" and "evidence_snippet" to null and explain the gap in "finding".
- Do not hallucinate sources. Only use [SOURCE_ID] values present in [EVIDENCE_SET].
- If [VERIFICATION_POLICY] specifies a minimum number of corroborating sources, you must document each corroborating source as a separate step.
- If sources contradict each other, you must add a step documenting the contradiction and explaining why one source was preferred, referencing [VERIFICATION_POLICY] rules on authority or recency.
- The "confidence" field reflects your certainty in that specific step's finding, not the overall claim.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific data and policies. The [CLAIMS] placeholder should be populated with the output of an upstream claim extraction prompt to ensure atomicity. The [EVIDENCE_SET] must be a structured list of your retrieved documents, each with a unique, stable identifier to prevent citation hallucination. The [VERIFICATION_POLICY] is critical; it should define concrete rules like 'prefer peer-reviewed sources over news articles' or 'require two corroborating sources for financial figures.' The [EXAMPLES] placeholder should contain 1-2 few-shot examples of a complete, correct evidence chain to anchor the model's output format and reasoning depth. For high-risk domains, set [RISK_LEVEL] to 'high' and ensure a human-review step is enforced in your application harness before any output is finalized.

The Evidence Chain Construction Prompt is not a standalone tool—it is a verification engine that must be embedded in a deterministic harness. For audit and compliance use cases, the harness must enforce that every claim receives a traceable verdict before the output is accepted. This means the application layer must manage claim ingestion, evidence retrieval, model invocation, output validation, and final packaging. The prompt itself handles the reasoning, but the harness owns the workflow integrity.

Begin by extracting claims upstream using a dedicated Claim Extraction prompt. Feed each claim individually (or in small batches of 3–5) into the Evidence Chain prompt along with retrieved evidence from your knowledge base, vector store, or document repository. The harness must track a claim_id through every step. After the model returns a chain, validate the output structurally: confirm that every claim in the input appears in the output with a non-null verification_status, that each evidence reference includes a retrievable source_id and chunk_id, and that the chain_steps array is non-empty. Reject and retry any response that fails structural validation. For high-stakes audits, implement a second-pass completeness check using a separate prompt that scores the chain for missing reasoning steps or unaddressed sub-claims.

Model choice matters here. Use a model with strong reasoning capabilities and long-context handling, such as GPT-4o or Claude 3.5 Sonnet, because evidence chains require multi-step logical threading. Set temperature=0 for deterministic outputs. Implement a retry loop with exponential backoff (1s, 2s, 4s) for malformed responses, capped at 3 attempts. After 3 failures, route the claim to a human review queue with the raw evidence and model attempts attached. Log every chain generation attempt—including the prompt version, model, retrieved evidence IDs, and validation results—to create an audit trail of the verification process itself. Never silently accept a partial or unvalidated chain in a compliance workflow.

For production deployment, consider batching claims by document or topic to reduce context-switching costs, but keep batches small enough that a single failure does not require reprocessing a large set. If your evidence retrieval system returns empty results, the harness should short-circuit and mark the claim as UNVERIFIABLE with a note that no evidence was found, rather than passing an empty context to the model and risking hallucinated justifications. Finally, build a human approval step for any chain where the model flags a contradiction or where confidence scores fall below your organization's threshold. The prompt produces the reasoning; the harness ensures that reasoning is complete, grounded, and reviewable.