Evidence Corroboration Report Prompt

This prompt is for verification engineers and pipeline developers who need to assess multi-source agreement on a set of claims. It takes a list of claims and their associated evidence from multiple sources and produces a structured corroboration report. The report identifies corroboration patterns, builds a source agreement matrix, flags outlier evidence, and detects false consensus where multiple sources repeat the same unverified claim. Use this prompt after claim extraction and evidence matching steps are complete. It is not a substitute for those upstream processes. The output is designed to feed into audit trails, human review queues, and confidence scoring systems.

The ideal user has already run claim extraction against source content and evidence matching against a knowledge base or document set. You should have a structured input containing at minimum: a unique claim ID per assertion, the claim text, and a list of evidence records with source identifiers and relevance scores. This prompt assumes the evidence has already been retrieved and paired with claims. It does not perform retrieval, claim decomposition, or source authority assessment. If you need those capabilities, use the upstream prompts for claim extraction, evidence matching, and source authority documentation before invoking this corroboration step.

Do not use this prompt when you have fewer than two sources per claim, when evidence has not been matched to claims, or when you need a binary true/false verdict. This prompt analyzes agreement patterns, not individual claim truth values. It is also not a replacement for human judgment in high-stakes domains. The false-consensus detection logic can identify when multiple sources echo the same unverified claim, but it cannot verify the underlying facts independently. Always route outputs through human review for claims with regulatory, legal, or safety implications. The report should be treated as an analytical input to decision-making, not a final determination.

This prompt template is the core instruction set for generating an Evidence Corroboration Report. It is designed to be copied directly into your application or testing environment. The template uses square-bracket placeholders, such as [CLAIMS_AND_EVIDENCE], which you must replace with your actual data before sending it to the model. The prompt instructs the model to analyze multi-source agreement, construct a source agreement matrix, and identify outlier evidence, all while adhering to a strict output schema.

textCopy
You are a meticulous verification engineer. Your task is to analyze a set of claims and their associated evidence to produce a structured Evidence Corroboration Report.

**INPUT DATA**
[CLAIMS_AND_EVIDENCE]

**INSTRUCTIONS**
1.  **Analyze Corroboration:** For each claim, analyze the provided evidence sources to determine the level of agreement. Categorize the evidence as 'Supporting', 'Contradicting', or 'Contextual/Neutral'.
2.  **Construct Agreement Matrix:** Create a matrix mapping each claim to its evidence sources and their support status.
3.  **Identify Outliers:** Flag any evidence that is a significant outlier, either strongly contradicting a consensus or being the sole source for a critical point. Explain why it is an outlier.
4.  **Detect False Consensus:** Check for patterns where multiple sources appear to agree but are likely citing the same single origin or are not independent. Flag this as a potential false consensus.
5.  **Generate Report:** Compile your findings into the final report, adhering strictly to the [OUTPUT_SCHEMA].

**CONSTRAINTS**
- Do not introduce new information not present in the [CLAIMS_AND_EVIDENCE].
- If evidence for a claim is missing or insufficient, explicitly state that corroboration could not be determined.
- For each claim, provide a concise 'Corroboration Summary' (e.g., 'Strongly Corroborated', 'Partially Corroborated', 'Contradicted', 'Insufficient Evidence').
- The report must be a valid JSON object matching the [OUTPUT_SCHEMA].

**OUTPUT SCHEMA**
```json
{
  "report_title": "Evidence Corroboration Report",
  "generated_at": "[TIMESTAMP]",
  "claims_analyzed": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "corroboration_summary": "Strongly Corroborated | Partially Corroborated | Contradicted | Insufficient Evidence",
      "agreement_matrix": [
        {
          "source_id": "string",
          "source_excerpt": "string",
          "support_status": "Supporting | Contradicting | Contextual/Neutral"
        }
      ],
      "outlier_evidence": [
        {
          "source_id": "string",
          "reason_for_outlier_status": "string"
        }
      ],
      "false_consensus_flag": {
        "is_potential_false_consensus": true,
        "rationale": "string"
      }
    }
  ],
  "overall_assessment": "string"
}

To adapt this template, replace the [CLAIMS_AND_EVIDENCE] placeholder with a structured data object containing your claims and evidence. The [OUTPUT_SCHEMA] is provided inline as a JSON block for the model to follow. For high-stakes verification, always implement a post-generation validation step to check the JSON structure and confirm that every 'Supporting' or 'Contradicting' status in the agreement matrix is directly traceable to a source excerpt provided in the input. A human review step is required before using this report for compliance or regulatory purposes.

The Evidence Corroboration Report Prompt is designed to operate as a mid-pipeline component that receives pre-extracted claims and matched evidence from upstream retrieval and matching steps. Do not feed raw documents directly into this prompt. The input should already contain structured claim objects with associated evidence records, source identifiers, and any preliminary confidence scores from earlier pipeline stages. This separation ensures the corroboration analysis focuses on agreement patterns rather than duplicating extraction or retrieval work.

Wire this prompt into your application by constructing a request payload with the following required fields: [CLAIMS] as an array of claim objects each containing claim_id, claim_text, and evidence_sources (an array of source objects with source_id, excerpt, and relevance_score). Include [CORROBORATION_THRESHOLD] to define the minimum number of agreeing sources required for a 'corroborated' label, and [OUTPUT_SCHEMA] specifying the expected JSON structure with fields for corroboration_matrix, agreement_clusters, outlier_evidence, and false_consensus_flags. After receiving the model response, validate the output against the schema immediately. Check that every claim_id in the input appears in the output matrix, that agreement clusters contain at least two sources, and that outlier evidence entries include explicit reasoning for their exclusion. If validation fails, retry once with the validation errors appended to the prompt as [PREVIOUS_ERRORS]. If the second attempt also fails, route the batch to a human reviewer with the partial output and error context.

For high-stakes verification workflows, implement a human review gate after successful validation. Flag reports where the false-consensus detection check identifies potential echo-chamber patterns—multiple sources agreeing but all deriving from a single origin source. Also flag reports where the corroboration-accuracy score falls below a configurable threshold (we recommend starting at 0.7 and calibrating based on domain requirements). Log every report generation event with the model version, input hash, output hash, validation status, and reviewer decision. This audit trail is essential for governance use cases. Avoid using this prompt for real-time or latency-sensitive applications; the multi-source comparison logic benefits from models with strong reasoning capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent) and typical response times range from 3-10 seconds depending on claim volume. For batch processing, implement a queue with configurable parallelism and a dead-letter queue for reports that exhaust retry budgets.