Multi-Claim Batch Verification Report Prompt

This prompt is designed for platform engineers and verification pipeline operators who need to produce a single, structured batch summary report after processing a large volume of claims. Its job is to synthesize pre-computed verification results—each with a verdict, confidence score, and evidence references—into a consolidated output. The report includes per-claim verdicts, aggregate statistics, and outlier detection, serving as the final reporting stage before human review or audit submission. The ideal user is someone running an automated fact-checking pipeline who needs a reliable, machine-readable summary, not someone performing the initial verification.

This prompt assumes a strict upstream contract: every claim in the input batch has already been individually verified against evidence sources by a prior pipeline stage. The input must contain a list of claims, each with a pre-computed verdict (e.g., SUPPORTED, CONTRADICTED, UNVERIFIABLE), a confidence_score (0.0 to 1.0), and an array of evidence_references with source identifiers. The prompt does not retrieve evidence, compare claims to sources, or determine verdicts. It synthesizes, summarizes, and flags anomalies across the batch. Using it for per-claim verification logic, evidence retrieval, or source attribution will produce misleading results, as the prompt has no access to external knowledge and will hallucinate if forced to perform those tasks.

Do not use this prompt when you need to verify individual claims, retrieve supporting documents, or generate source attributions from scratch. Those responsibilities belong to upstream components in your verification pipeline, such as evidence matching and claim scoring prompts. This prompt is also unsuitable for generating narrative audit trails for non-technical stakeholders; use a dedicated audit trail narrative prompt for that purpose. Before implementing, ensure your upstream pipeline reliably outputs the required fields for every claim. Missing or malformed inputs will cause the batch report to be incomplete or misleading. The next step is to review the prompt template and wire it into your application with strict input validation and output schema checks.

This prompt template is the core instruction set for the Multi-Claim Batch Verification Report. It is designed to be pasted directly into your verification pipeline, with square-bracket placeholders replaced by actual data at runtime. The prompt instructs the model to process a batch of claims, evaluate each against provided evidence, and produce a structured JSON report containing per-claim verdicts, aggregate statistics, and outlier detection. This is not a conversational prompt; it is a machine-to-machine instruction for a stateless API call.

textCopy
You are a batch verification report generator. Your task is to process a list of claims and their associated evidence to produce a structured verification report.

## INPUT DATA
- Claims: [CLAIMS_JSON_ARRAY]
- Evidence Pool: [EVIDENCE_JSON_OBJECT]

## TASK
For each claim in the Claims array, perform the following:
1. Locate all relevant evidence snippets in the Evidence Pool using the claim's `evidence_ids` field.
2. Evaluate whether the evidence SUPPORTS, CONTRADICTS, or is INSUFFICIENT for the claim.
3. Assign a confidence score between 0.0 and 1.0.
4. Generate a one-sentence rationale for the verdict.

After processing all claims, compute aggregate statistics and identify outliers.

## OUTPUT_SCHEMA
You must output a single JSON object conforming to this structure:
{
  "report_id": "string",
  "generated_at": "ISO 8601 timestamp",
  "batch_summary": {
    "total_claims": "integer",
    "supported_count": "integer",
    "contradicted_count": "integer",
    "insufficient_evidence_count": "integer",
    "average_confidence": "float"
  },
  "outliers": [
    {
      "claim_id": "string",
      "reason": "string (e.g., 'low confidence', 'high contradiction rate', 'evidence mismatch')"
    }
  ],
  "claims_verification": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "verdict": "SUPPORTS | CONTRADICTS | INSUFFICIENT_EVIDENCE",
      "confidence": "float",
      "rationale": "string",
      "evidence_used": ["string (evidence_id)"]
    }
  ]
}

## CONSTRAINTS
- Do not hallucinate evidence. Only use evidence_ids present in the input.
- If a claim has no evidence_ids, the verdict must be INSUFFICIENT_EVIDENCE with a confidence of 0.0.
- An outlier is any claim with confidence < 0.5 or a verdict of CONTRADICTS.
- The `report_id` must be the value provided in [REPORT_ID].
- Output only the JSON object. No markdown fences, no extra text.

To adapt this template, replace the placeholders with your application's data. [CLAIMS_JSON_ARRAY] should be a JSON array of claim objects, each with an id, text, and evidence_ids array. [EVIDENCE_JSON_OBJECT] should be a JSON object mapping evidence IDs to their text content. [REPORT_ID] is a unique identifier for the batch run, typically a UUID. Before deploying, test the prompt with a small, known batch of claims and evidence to ensure the output schema is strictly adhered to and that outlier detection logic matches your risk thresholds. For high-stakes domains, always route CONTRADICTS and low-confidence claims to a human review queue as defined in your implementation harness.

The Multi-Claim Batch Verification Report prompt is designed to sit at the end of a verification pipeline, consuming structured claim-evidence pairs and producing a summary report. It is not a standalone fact-checker. Before calling this prompt, you must have already extracted claims, retrieved evidence, and performed per-claim matching. The prompt's job is synthesis: aggregating individual verdicts, computing batch statistics, detecting outliers, and flagging consistency issues across the batch. Wire it as a post-processing step that runs after all individual claim verifications complete, not as a replacement for them.

Implement this prompt inside a validation wrapper that checks the output before it reaches downstream consumers. The wrapper should: (1) validate that the JSON schema matches the expected report structure, including required fields like batch_summary, per_claim_verdicts, and outlier_flags; (2) cross-check that every claim ID in the input appears in the output with a non-null verdict; (3) verify that aggregate statistics (total claims, supported, contradicted, unsupported counts) sum correctly to the batch size; and (4) confirm that any flagged outliers include a specific reason and the claim ID they reference. If validation fails, retry the prompt once with the validation errors appended to the [CONSTRAINTS] block. If the second attempt also fails, route the batch to a human review queue with the raw per-claim results and the failed validation report attached.

For model choice, use a model with strong JSON-following behavior and a context window large enough to hold your full batch of claim-evidence pairs plus the prompt template. GPT-4o, Claude 3.5 Sonnet, and Gemini 1.5 Pro are all suitable. If your batch exceeds 50 claims, split it into sub-batches of 25-30 claims and run the prompt in parallel, then merge the sub-reports with a final aggregation call. For logging, capture the prompt version, model, input claim count, validation pass/fail status, retry count, and any outlier claims flagged. This log becomes part of your audit trail and helps debug batch-consistency drift over time. Do not skip logging even when validation passes—production verification systems need traceability for every batch.

Human review integration is required for batches where outlier detection fires, where validation fails after retries, or where the batch_summary.consistency_score falls below a configured threshold (start with 0.85 and tune based on your domain risk tolerance). When routing to review, package the full prompt input, the raw model output, the validation results, and a pre-formatted review checklist that asks the reviewer to confirm or override each outlier flag and the overall consistency assessment. This structured handoff prevents reviewers from needing to reconstruct context and ensures audit-ready records of human decisions.

Avoid wiring this prompt directly into a customer-facing surface without the validation wrapper and human review escape hatch. The most common production failure mode is silent schema drift: the model returns valid JSON that passes a basic schema check but omits fields, misaligns claim IDs, or produces aggregate statistics that don't add up. The cross-validation checks described above catch these failures before they corrupt downstream dashboards or compliance reports. Test your harness with intentionally malformed inputs—missing claims, duplicate claim IDs, empty evidence arrays—to verify that validation and retry logic behaves correctly under edge conditions.