Claim-to-Evidence Traceability Matrix Prompt

This prompt is for audit, compliance, and governance teams who need to prove that every factual claim in a document has been checked against evidence. It produces a traceability matrix mapping each discrete claim to its evidence sources, verification status, and coverage gaps. Use this when you need a complete verification coverage map, not just a list of supported or contradicted claims. This prompt assumes claims have already been extracted from the source content. If you need claim extraction first, pair this with a claim decomposition prompt from the Claim Extraction and Decomposition content group.

The ideal user is a verification pipeline operator or compliance analyst who has a list of atomic claims and a set of evidence documents, and needs to demonstrate exhaustive coverage to an auditor or internal reviewer. The required context includes the full set of claims with unique identifiers, the evidence corpus with source metadata, and any domain-specific evidence standards that define what counts as sufficient support. The output is a structured matrix—not a narrative summary—that shows every claim, its matched evidence, verification status (supported, contradicted, insufficient, or not checked), and explicit gap flags for claims that could not be verified.

Do not use this prompt when you need a simple supported/unsupported binary label, when you lack claim identifiers for traceability, or when the evidence corpus is too large to fit in context without retrieval augmentation. For those cases, use the Evidence Sufficiency Assessment Prompt for binary decisions or pair this prompt with a retrieval step that pre-filters evidence per claim. Also avoid this prompt when the goal is to generate a prose audit report; the matrix output is a structured artifact meant for downstream processing or human review, not a final narrative deliverable. For narrative reports, chain this prompt's output into a Verification Report and Audit Trail Generation prompt.

This prompt is designed for audit and compliance workflows where every extracted claim must be explicitly mapped to supporting or contradicting evidence, and any unaddressed claims must be surfaced as coverage gaps. The prompt expects all claims and all evidence to be provided in context—it does not perform retrieval. Use this when you already have a set of extracted claims and a corpus of source documents, and you need a structured matrix showing exactly which evidence addresses which claim, with verification status and gap detection.

textCopy
You are a verification auditor producing a claim-to-evidence traceability matrix. Your output must be complete, structured, and suitable for compliance review.

## INPUT

### Claims
[CLAIMS]

### Evidence Sources
[EVIDENCE_SOURCES]

## TASK

For each claim in [CLAIMS], determine whether the provided [EVIDENCE_SOURCES] contain information that supports, contradicts, or fails to address the claim. Produce a traceability matrix that maps every claim to its relevant evidence with verification status.

## CONSTRAINTS

- Every claim in [CLAIMS] must appear in the output matrix. No claim may be omitted.
- If a claim has no matching evidence in [EVIDENCE_SOURCES], mark it as "UNVERIFIED" and document the gap.
- If evidence partially addresses a claim, mark it as "PARTIAL" and specify which components are covered and which are not.
- Do not infer evidence beyond what is explicitly present in [EVIDENCE_SOURCES].
- Quote the specific passage from the evidence source that supports or contradicts each claim.
- If multiple evidence sources address the same claim, include all of them with their individual statuses.
- If evidence sources contradict each other on the same claim, flag the conflict explicitly.

## OUTPUT SCHEMA

Return a JSON object with the following structure:

{
  "matrix": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verification_status": "SUPPORTED | CONTRADICTED | PARTIAL | UNVERIFIED | CONFLICT",
      "evidence_matches": [
        {
          "source_id": "string",
          "source_reference": "string",
          "quoted_evidence": "string",
          "match_type": "SUPPORTS | CONTRADICTS | PARTIAL",
          "match_explanation": "string"
        }
      ],
      "coverage_gap": "string | null"
    }
  ],
  "summary": {
    "total_claims": "number",
    "supported_count": "number",
    "contradicted_count": "number",
    "partial_count": "number",
    "unverified_count": "number",
    "conflict_count": "number",
    "coverage_gaps": ["string"]
  }
}

## RULES

- "claim_id" must match the identifier provided in [CLAIMS].
- "source_id" must match the identifier provided in [EVIDENCE_SOURCES].
- "coverage_gap" must be null if verification_status is SUPPORTED or CONTRADICTED. For UNVERIFIED claims, describe what evidence would be needed. For PARTIAL claims, describe which claim components lack evidence.
- "quoted_evidence" must be a verbatim excerpt from the evidence source, not a paraphrase.
- If [EVIDENCE_SOURCES] is empty or contains no relevant evidence for any claim, all claims must be marked UNVERIFIED with appropriate gap descriptions.

To adapt this prompt, replace [CLAIMS] with a structured list of claims including unique identifiers and full claim text. Replace [EVIDENCE_SOURCES] with a structured list of source documents including identifiers, references, and full text. The prompt expects both inputs to be pre-processed and formatted before insertion. If your claims or evidence sources lack identifiers, generate them in your preprocessing step. For high-stakes audit workflows, add a [RISK_LEVEL] parameter that adjusts the strictness of partial-match handling and the verbosity of coverage gap descriptions. Always validate the output JSON against the schema before accepting results, and route any matrix with UNVERIFIED claims exceeding your risk threshold to human review.

This prompt is typically the final stage in a multi-step verification workflow. The upstream pipeline should handle claim extraction, evidence retrieval, and deduplication before this prompt runs. The prompt expects a structured input containing a list of claims with unique IDs and a set of evidence sources with identifiers. It produces a matrix mapping every claim to its evidence, verification status, and gap flags. Do not use this prompt for initial claim extraction or evidence retrieval—it assumes those steps are complete and focuses solely on traceability mapping and coverage documentation.

In production, wrap this prompt in a validation layer that checks every claim ID from the input appears in the output matrix. Missing claim IDs in the output indicate a model truncation or attention failure, especially with large claim sets. Implement a post-processing validator that extracts all claim IDs from the input, extracts all claim IDs from the output matrix, and computes the set difference. If any input claims are missing from the output, log the mismatch and retry with a reduced batch size or explicit instruction to include all claims. For high-stakes audit workflows, route any claim with INSUFFICIENT status or gap_flag: true to a human review queue with the full evidence context attached—do not auto-resolve these claims downstream. Log the complete prompt, output, and validation results for audit trail purposes. Consider running this prompt with temperature=0 and a strict JSON mode to maximize output consistency across runs. If your model provider supports structured output constraints, supply the expected JSON schema directly rather than relying on prompt-level format instructions alone.

When integrating this into a pipeline, set a maximum claim batch size based on your model's context window and observed attention reliability. Claims with long evidence passages may require smaller batches. Implement a retry strategy: if validation detects missing claims or malformed JSON, retry once with the same input and a stronger format reminder. If the second attempt fails, split the batch in half and retry each half separately. For audit and compliance use cases, store the full prompt, raw model output, validation results, and any human review decisions in an append-only log with timestamps and model version identifiers. Never silently drop claims that fail verification—every claim must appear in the output matrix or be explicitly flagged as unprocessed with a documented reason.