Cross-Format Claim-Evidence Pair Extraction Prompt

This prompt is designed for pipeline builders who need to extract structured, verifiable claim-evidence pairs from source sets that span multiple formats. Use it when your input includes a mix of text passages, table snippets, chart descriptions, image captions, or audio transcript segments, and you need a normalized output that links each claim to its supporting or contradicting evidence with format-aware provenance. The ideal user is an AI engineer or verification system architect integrating this extraction step into a larger fact-checking or content-audit pipeline. The required context is a pre-assembled set of source materials—this prompt does not perform retrieval or search. It assumes the claims and evidence are already present in the provided material and focuses solely on structuring them for downstream consumption.

This prompt is not a fact-checking verdict generator. It produces the structured pairs that downstream verification, scoring, and human-review prompts consume. Do not use this prompt for open-domain retrieval or for generating claims from model parametric knowledge. It is also unsuitable for single-format inputs where a simpler extraction prompt would suffice; the added complexity of format-aware provenance tracking is only warranted when your source set genuinely mixes modalities. In high-risk domains such as healthcare, finance, or legal, the output of this prompt must feed into a human-review step before any automated action is taken. The prompt does not assess claim truthfulness, source authority, or evidence sufficiency—it only structures what is present.

Before implementing, confirm that your upstream process can supply the required [SOURCE_SET] with format-type metadata for each source segment. If your pipeline cannot reliably tag source formats, the prompt's format-aware provenance features will degrade. After extraction, validate the output against the expected [OUTPUT_SCHEMA] using a schema validator before passing results to downstream matching or scoring prompts. Common failure modes include claim fragmentation across format boundaries and evidence links that reference the wrong source segment—both should be caught by eval suites that test cross-format alignment integrity. Start with a small, manually annotated golden dataset spanning your target format combinations before scaling to production volumes.

This template is designed to be dropped directly into a verification pipeline. It accepts a mixed-format source set—text passages, table snippets, image descriptions, audio transcript segments, or chart data summaries—and outputs a normalized JSON array of claim objects. Each claim object ties a discrete factual assertion to its supporting or contradicting evidence, records the source format, and includes a cross-format alignment score. The prompt enforces strict output schema compliance and requires the model to abstain from inventing evidence not present in the provided sources.

textCopy
You are a claim-evidence extraction system operating inside a verification pipeline. Your output will be validated by a downstream schema checker and may be routed to human review if confidence is low.

## INPUT

[INPUT]

## OUTPUT SCHEMA

Return ONLY a valid JSON object with this structure:

{
  "claims": [
    {
      "claim_id": "string (unique identifier for this claim)",
      "claim_text": "string (the exact factual assertion, normalized and atomic)",
      "source_format": "string (one of: text, table, chart, image, audio_transcript, video_segment, infographic, diagram, slide_deck, screenshot, unknown)",
      "source_location": "string (pointer to where the claim appears in the source, e.g., paragraph index, cell reference, timestamp, slide number)",
      "evidence": [
        {
          "evidence_id": "string (unique identifier for this evidence item)",
          "evidence_text": "string (the supporting or contradicting evidence, quoted or described precisely)",
          "evidence_source_format": "string (format of the evidence source)",
          "evidence_source_location": "string (pointer to where the evidence appears)",
          "relationship": "string (one of: supports, contradicts, partially_supports, insufficient, unrelated)",
          "alignment_score": "number (0.0 to 1.0, how well the evidence aligns with the claim across formats)",
          "alignment_notes": "string (explanation of alignment score, especially for cross-format comparisons)"
        }
      ],
      "normalization_notes": "string (any transformations applied to make the claim atomic and comparable across formats)",
      "cross_format_flags": ["string (list of format-specific concerns, e.g., OCR_ambiguity, chart_axis_misalignment, transcription_uncertainty, aggregation_mismatch)"],
      "confidence": "number (0.0 to 1.0, overall confidence in the claim-evidence pairing)",
      "requires_human_review": "boolean (true if confidence < [REVIEW_THRESHOLD] or cross-format conflicts exist)"
    }
  ],
  "extraction_metadata": {
    "total_claims_found": "number",
    "claims_with_evidence": "number",
    "claims_without_evidence": "number",
    "cross_format_conflicts": "number",
    "extraction_notes": "string (summary of extraction decisions, format challenges, and abstentions)"
  }
}

## CONSTRAINTS

[CONSTRAINTS]

## EXAMPLES

[EXAMPLES]

## INSTRUCTIONS

1. Extract every discrete factual assertion from the input as an atomic claim. Do not merge multiple claims into one.
2. For each claim, search ALL provided sources for evidence that supports or contradicts it. Evidence may reside in a different format than the claim.
3. When comparing across formats, account for format-specific interpretation challenges: OCR errors in images, axis scaling in charts, transcription errors in audio, aggregation levels in tables vs. text.
4. Set alignment_score based on semantic and factual alignment, not surface-level keyword matching. A score of 1.0 means the evidence directly and unambiguously addresses the claim.
5. Flag claims with insufficient evidence by setting relationship to "insufficient" and alignment_score to 0.0. Do not fabricate evidence.
6. Set requires_human_review to true when confidence is below [REVIEW_THRESHOLD], when cross-format conflicts exist, or when format-specific flags indicate extraction uncertainty.
7. If the input contains no extractable claims, return an empty claims array with appropriate extraction_metadata.
8. Do not include claims that are opinions, predictions, or rhetorical statements unless they contain embedded factual assertions that can be verified.

To adapt this template for your pipeline, replace the square-bracket placeholders with concrete values. [INPUT] should contain your mixed-format source set, clearly delimited with format labels so the model can distinguish a text passage from a table snippet or an audio transcript segment. [CONSTRAINTS] should specify domain-specific rules—for example, numerical tolerance windows for financial claims, required citation formats for legal evidence, or prohibited claim types. [EXAMPLES] should include at least two few-shot demonstrations showing correct claim-evidence pair extraction, including one cross-format example where a claim from a text source is verified against a table or chart. Set [REVIEW_THRESHOLD] to your pipeline's confidence cutoff for automatic vs. human-reviewed claims; 0.7 is a common starting point for high-stakes domains. After adapting, validate the output against your schema before allowing it to flow into downstream verification or reporting steps.

The Cross-Format Claim-Evidence Pair Extraction Prompt is a critical first stage in a multimodal verification pipeline. It ingests a mixed-format source set—text documents, tables, images, audio transcripts, video segments—and outputs normalized claim objects with format-typed evidence references. Because downstream verification accuracy depends entirely on clean claim boundaries and correct evidence linkage, the harness around this prompt must enforce structural integrity before any claim reaches an evidence-matching or scoring stage. Treat the prompt's output as a structured data contract, not a conversational response.

Implement a validation layer that checks every output object against a strict schema before allowing it to proceed. Each extracted claim must contain: a unique claim ID, the atomic claim text, a source_format enum value (e.g., text, table, chart, image_ocr, audio_transcript, video_segment), a source_location pointer (page number, cell range, timestamp, frame index), and an evidence_snippet with the exact text or structured data that grounds the claim. Reject any claim object missing these fields and trigger a retry with the specific validation error injected into the retry prompt context. For cross-format alignment scores, validate that the score is a float between 0.0 and 1.0 and that the alignment_rationale field is non-empty. Log every validation failure with the raw model output and the rejection reason for prompt debugging.

Build a retry loop with a maximum of two attempts. On the first validation failure, append the schema violation details to the original prompt and re-invoke the model. If the second attempt also fails validation, route the entire source set to a human-review queue with the partial output and error log attached. Do not silently drop failed extractions—partial claim sets can still contain usable data, but they require human judgment before entering the verification pipeline. For high-volume production, implement a circuit breaker that pauses extraction if the failure rate exceeds 15% in a rolling five-minute window, indicating a possible prompt drift or model behavior change.

Model choice matters for cross-format extraction. Use a model with strong multimodal reasoning capabilities and a large context window if your source sets include images, charts, or long transcripts. For text-only source sets, a faster text model may suffice, but ensure it can handle structured table inputs if tables are present. Implement format-aware routing: if the input set contains only text and tables, route to a text-optimized model; if images, charts, or video frame descriptions are present, route to a multimodal model. This routing decision should happen before the prompt is assembled, based on a pre-scan of the source set's format types.

Grounding is the highest-risk failure mode in cross-format extraction. The model may hallucinate claims that are not present in the source material, especially when interpreting charts, images, or audio. Implement a post-extraction grounding check that verifies each claim's evidence_snippet is a verbatim or near-verbatim match to content in the original source. For text sources, use substring or fuzzy matching. For structured data sources, validate that extracted values fall within the source's reported ranges. For image and chart claims, flag any extraction where the model cannot point to a specific visual element. Claims that fail grounding verification should be downgraded to UNVERIFIED status and routed for human review, never silently treated as valid.

Finally, instrument the entire harness with observability hooks. Log every extraction request with: source set identifiers, format composition, model used, extraction latency, claim count, validation pass/fail status, retry count, and grounding check results. Emit metrics on extraction throughput, validation failure rate by format type, and grounding failure rate. These metrics will reveal which formats cause the most extraction errors and where prompt improvements are needed. Before deploying any prompt change, run a regression test suite of 50+ mixed-format source sets with known claim counts and evidence locations to catch regressions in extraction recall or precision.