Audio-Transcript-Claim-to-Document-Evidence Matching Prompt

This prompt is designed for a specific verification job: you have an audio transcript containing factual claims made by identifiable speakers, and you have a set of written documents that should contain supporting or contradicting evidence. The prompt's job is to bridge these two formats. It extracts speaker-attributed claims from the transcript, searches the provided document corpus, and returns structured claim-evidence pairs with timestamped citations and mismatch flags. The ideal user is a verification engineer, analyst, or investigator working in domains like legal review, compliance auditing, earnings call analysis, or editorial fact-checking, where spoken statements must be reconciled against a written record of truth.

This workflow is appropriate when you have a completed transcript and a static, pre-defined document set. It is not suitable for real-time audio processing, for verifying claims against live databases or APIs, or when the transcript quality is too poor to reliably identify speakers and statements. Before using this prompt, you must confirm that your transcript includes speaker diarization and timestamps, and that your document corpus is chunked and indexed for retrieval. The prompt assumes you have already solved the retrieval problem—it focuses on the matching and verification logic, not on search infrastructure. If your documents are not pre-chunked, you will need to add a retrieval step before invoking this prompt, or include the relevant document chunks directly in the [CONTEXT] placeholder.

A critical constraint is that this prompt verifies claims against the provided documents only. It does not assess whether the documents themselves are accurate, authoritative, or complete. If a speaker makes a true claim but the document set lacks the evidence, the prompt will flag it as unsupported—not false. This distinction is essential for audit trails and human review routing. You should pair this prompt with a source authority assessment step if document credibility is in question. Additionally, the prompt flags tone-vs-text sentiment mismatches, which is useful for detecting when a speaker's confident delivery masks a weak evidentiary basis, but this feature should be tested carefully in your domain to avoid over-flagging normal rhetorical patterns.

To get started, prepare your transcript in a structured format with speaker labels and timestamps, assemble your document evidence set, and define your output schema. The prompt template in the next section is copy-ready and uses square-bracket placeholders for all variable inputs. After adapting it, run a small batch of known cases through the prompt and compare the outputs to human-verified ground truth before scaling to production volumes. Pay special attention to speaker disambiguation errors and transcription mistakes, as these cascade directly into false mismatch flags.

This template is designed to be copied directly into your prompt management system or codebase. It expects a pre-processed audio transcript with speaker labels and timestamps, along with one or more reference documents that may contain supporting or contradicting evidence. The prompt instructs the model to extract atomic claims from the transcript, search the provided documents for evidence, and return structured claim-evidence pairs with precise citations. Replace every square-bracket placeholder with concrete values before sending the prompt to the model. Do not leave any placeholder unresolved in production requests.

textCopy
You are a verification analyst. Your task is to match factual claims made by speakers in an audio transcript against evidence found in provided reference documents.

## INPUT

### Transcript
[TRANSCRIPT]

### Reference Documents
[DOCUMENTS]

## INSTRUCTIONS

1. Extract every factual claim from the transcript. A factual claim is a statement that can be verified or contradicted by documentary evidence. Ignore opinions, greetings, filler words, and procedural discussion.

2. For each claim, search the reference documents for evidence that supports, contradicts, or partially addresses the claim.

3. For each claim, produce a structured output record following the schema below.

4. If a claim cannot be matched to any evidence in the provided documents, mark it as UNVERIFIED and explain what evidence would be needed.

5. Pay special attention to tone and sentiment. If a speaker's tone in the transcript (as indicated by [TONE_MARKERS] or context) conflicts with the sentiment of the matching document passage, flag it as a TONE_TEXT_MISMATCH.

6. Use exact speaker labels from the transcript. Do not guess speaker identities.

## OUTPUT SCHEMA

Return a JSON array of claim-evidence pairs:

[
  {
    "claim_id": "string, unique identifier for this claim",
    "speaker": "string, speaker label from transcript",
    "transcript_timestamp_start": "string, HH:MM:SS or seconds",
    "transcript_timestamp_end": "string, HH:MM:SS or seconds",
    "claim_text": "string, the exact claim as stated",
    "verdict": "SUPPORTED | CONTRADICTED | PARTIALLY_SUPPORTED | UNVERIFIED",
    "evidence": [
      {
        "document_id": "string, identifier for the source document",
        "document_section": "string, section or paragraph reference",
        "evidence_text": "string, the relevant passage from the document",
        "relationship": "SUPPORTS | CONTRADICTS | PARTIALLY_ADDRESSES",
        "confidence": "HIGH | MEDIUM | LOW"
      }
    ],
    "tone_text_mismatch": {
      "detected": true | false,
      "transcript_tone": "string, brief description of speaker tone",
      "document_tone": "string, brief description of document passage tone",
      "explanation": "string, why the tones conflict"
    },
    "unverifiable_reason": "string or null, explanation if verdict is UNVERIFIED"
  }
]

## CONSTRAINTS

- Do not fabricate evidence. If a document does not contain relevant information, say so.
- Do not merge claims from different speakers into a single record.
- Timestamps must be taken directly from the transcript. Do not estimate.
- If the transcript contains overlapping speech, note it in the claim_text but attribute to the primary speaker.
- [ADDITIONAL_CONSTRAINTS]

## EXAMPLES

[FEW_SHOT_EXAMPLES]

## RISK LEVEL

[RISK_LEVEL]

Adapt this template by replacing the placeholders with your specific inputs. The [TRANSCRIPT] placeholder should contain the full transcript text with speaker labels and timestamps in a consistent format. The [DOCUMENTS] placeholder should contain one or more reference documents with clear section or paragraph identifiers for citation. If your transcript format includes explicit tone markers, describe them in [TONE_MARKERS]; otherwise, remove that reference. Add any domain-specific constraints to [ADDITIONAL_CONSTRAINTS], such as requiring exact quote matching or setting numerical tolerance windows. Provide 2-4 annotated examples in [FEW_SHOT_EXAMPLES] that demonstrate correct claim extraction, evidence matching, and tone-mismatch flagging for your use case. Set [RISK_LEVEL] to HIGH if the verification output will be used in regulatory, legal, or safety contexts, which should trigger human review of all UNVERIFIED and CONTRADICTED verdicts before the output is accepted.

This prompt is designed as a single step within a larger verification pipeline. It expects pre-processed inputs: a diarized transcript with speaker labels and timestamps, and a set of pre-retrieved document chunks. Do not feed raw audio or an entire document repository directly into this prompt. The upstream harness must handle audio transcription, speaker diarization, document chunking, and initial retrieval. The prompt's job is the precise alignment of spoken claims to text evidence, not retrieval or transcription.

Wire the prompt into an application by constructing a strict JSON request body. The [TRANSCRIPT] placeholder should be a list of speaker-tagged segments with speaker_id, timestamp_start, timestamp_end, and text fields. The [DOCUMENTS] placeholder should be a list of objects with doc_id, title, section, and text fields. The [CLAIMS] placeholder is optional; if omitted, instruct the model to first extract claims from the transcript. Implement a post-processing validation layer that checks every returned claim_evidence_pair for: (1) a non-empty speaker_id, (2) a timestamp_citation that falls within the source segment's boundaries, (3) a doc_citation with a valid doc_id present in the input, and (4) a match_status that is one of supported, contradicted, partially_supported, or unverifiable. Discard or flag any pair that fails validation and log the failure for prompt debugging.

For high-stakes verification (compliance, legal, or audit use cases), route all outputs where match_status is contradicted or unverifiable to a human review queue. Package the original transcript segment, the retrieved document snippet, and the model's reasoning into a structured review task. For tone_vs_text_sentiment_mismatch flags, implement a secondary check: extract the quoted text from the document and run a separate sentiment analysis comparison before surfacing to a reviewer, as tone interpretation is highly subjective. Use a model with strong instruction-following and long-context handling, such as claude-sonnet-4-20250514 or gpt-4o, and set a low temperature (0.0–0.2) to maximize deterministic citation formatting. Implement a retry loop with a maximum of two attempts: if validation fails, re-submit the failed claim with the specific validation error message appended to the [CONSTRAINTS] field, asking the model to correct the citation format.

Common failure modes in production include: (1) transcription errors causing claim text to mismatch document phrasing, leading to false unverifiable results—mitigate by passing a confidence score from your ASR system and lowering the match threshold for low-confidence segments; (2) speaker diarization errors attributing claims to the wrong speaker—log speaker-change boundaries and flag claims near those boundaries for higher scrutiny; (3) the model fabricating document citations that sound plausible but reference non-existent sections—the doc_id and section validation step is critical to catch this. Monitor the rate of validation failures and unverifiable results by speaker and document source to detect upstream data quality issues before they corrupt the verification pipeline.