Evidence Gap Analysis Report Prompt

This prompt is designed for verification pipeline operators and platform engineers who need to audit their evidence coverage systematically. Use it after running claim extraction and evidence matching across a batch of content to identify where your retrieval or knowledge base consistently fails to provide adequate evidence. The output is a structured gap analysis report that categorizes missing evidence types, maps them to affected claims, and recommends prioritized remediation actions. This is not a per-claim verification prompt. It is a meta-analysis prompt that operates on aggregated verification results to surface systemic weaknesses in your evidence supply chain.

Deploy this prompt when you observe a pattern of UNSUPPORTED or INSUFFICIENT_EVIDENCE verdicts across multiple verification runs and need to understand the root cause before making infrastructure changes. The ideal input is a structured dataset containing at least 50-100 verification records, each with the original claim, the evidence retrieved, the verdict, and the evidence sources consulted. Without this volume, the gap analysis will lack statistical significance and may produce misleading recommendations. The prompt expects aggregated data, not raw documents or single claims. If you are still building your verification pipeline and lack production-scale results, start with the Structured Claim Verification Report Prompt Template to generate the per-claim records this prompt consumes.

Do not use this prompt for real-time verification decisions, single-claim analysis, or direct user-facing fact-checking. It is an offline diagnostic tool for pipeline improvement. The output is a strategic report meant for engineering and operations stakeholders who control retrieval configuration, knowledge base expansion, and search query tuning. Avoid running it on unvalidated verification outputs—if your upstream claim extraction or evidence matching prompts are producing noisy results, the gap analysis will amplify those errors. Validate your per-claim verification pipeline first using the eval checks in the Verification Error and Omission Report Prompt, then feed clean, representative data into this gap analysis. The next step after receiving the report is to prioritize the remediation actions by business impact and implement changes to your retrieval sources, embedding models, or search strategies before re-running the verification batch.

This prompt template is designed to be the core instruction set for an LLM tasked with analyzing systematic evidence coverage gaps across a batch of verified claims. It expects structured inputs—claims, their verdicts, and the evidence sources consulted—and produces a categorized report identifying missing evidence types, affected claims, and prioritized remediation steps. The template uses square-bracket placeholders that your application must replace with real data before sending the request to the model. Do not send this template with the placeholders unresolved.

textCopy
You are an evidence audit specialist. Your task is to analyze a batch of verified claims and produce an Evidence Gap Analysis Report. The report must identify systematic gaps in evidence coverage, categorize missing evidence types, list affected claims, and recommend remediation actions prioritized by risk.

# INPUTS
- Claims and Verdicts: [CLAIMS_AND_VERDICTS_JSON]
- Evidence Sources Consulted: [EVIDENCE_SOURCES_JSON]
- Verification Methodology: [METHODOLOGY_DOCUMENT]
- Domain Context: [DOMAIN_CONTEXT]

# OUTPUT SCHEMA
Produce a JSON object conforming to this structure:
{
  "report_id": "string",
  "generated_at": "ISO8601 timestamp",
  "summary": {
    "total_claims_analyzed": "integer",
    "claims_with_sufficient_evidence": "integer",
    "claims_with_evidence_gaps": "integer",
    "gap_categories_identified": ["string"]
  },
  "gap_analysis": [
    {
      "gap_category": "string (e.g., 'Missing Primary Source', 'Outdated Evidence', 'Single-Source Dependency', 'Authority Mismatch', 'Format Inaccessibility')",
      "description": "string explaining the nature of this gap category",
      "severity": "critical | high | medium | low",
      "affected_claim_ids": ["string"],
      "evidence_that_should_exist": "string describing the type of evidence that would close this gap",
      "remediation": {
        "action": "string describing the recommended remediation step",
        "priority": "integer (1=highest)",
        "estimated_effort": "low | medium | high",
        "suggested_sources_or_queries": ["string"]
      }
    }
  ],
  "unaffected_claims": ["string (claim IDs with sufficient evidence)"],
  "recommendations_summary": "string providing an executive summary of the top remediation priorities"
}

# CONSTRAINTS
- Only flag a gap if evidence is genuinely insufficient for a reliable verdict. Do not flag gaps for claims where the available evidence is adequate.
- Base every gap finding strictly on the provided claims, verdicts, and evidence sources. Do not invent missing evidence that is not implied by the inputs.
- If a claim was marked 'UNSUPPORTED' or 'INSUFFICIENT_EVIDENCE' in the input, it must appear in the gap analysis.
- Prioritize gaps that affect multiple claims or high-risk claims.
- Do not include claims in `unaffected_claims` if they have any identified evidence gap.
- Use the domain context to calibrate what constitutes sufficient evidence for the subject matter.

# RISK LEVEL
[HIGH] This analysis informs decisions about evidence collection and verification completeness. In regulated domains, gaps in evidence coverage can have compliance implications. The output must be reviewed by a human before remediation actions are taken.

To adapt this template for your pipeline, replace each placeholder with live data. [CLAIMS_AND_VERDICTS_JSON] should contain an array of claim objects, each with a unique ID, the claim text, its verification verdict, and a confidence score. [EVIDENCE_SOURCES_JSON] should list every source consulted during verification, including its identifier, type, authority level, and recency. [METHODOLOGY_DOCUMENT] provides the verification methodology so the model understands what 'sufficient evidence' means in your context. [DOMAIN_CONTEXT] describes the subject domain—legal, financial, medical, scientific—so the model calibrates its gap severity judgments appropriately. After replacing placeholders, validate that the output JSON matches the schema before ingesting it into downstream systems. For high-stakes domains, route the generated report through a human review step before acting on remediation recommendations.

The Evidence Gap Analysis Report prompt is designed to be called after a batch verification run, not as a standalone chat interaction. It expects structured input—a list of claims, their verification outcomes, and the evidence sources consulted—and produces a structured gap report. In a production pipeline, this prompt sits downstream of claim extraction, evidence retrieval, and per-claim verification steps. The output is consumed by a gap remediation workflow, a human reviewer dashboard, or a compliance audit system. Do not use this prompt for real-time, single-claim analysis; it is built for aggregate coverage assessment across a batch.

Wire the prompt into your application by first assembling the required inputs: a JSON array of claims with their verification statuses, a JSON array of evidence sources with metadata, and any domain-specific coverage thresholds. Validate the input payload against a strict schema before calling the model. On the output side, parse the model's JSON response and validate it against the expected gap report schema—checking for required fields like gap_category, affected_claim_ids, missing_evidence_type, severity, and remediation. If validation fails, retry once with the validation errors appended to the prompt as feedback. If the retry also fails, log the failure and route to a human reviewer with the raw model output and validation errors attached. For high-stakes domains like healthcare or finance, always require human sign-off on gap reports before they trigger downstream actions such as evidence re-retrieval or public disclosure of coverage limitations.

Model choice matters here. Use a model with strong JSON mode and long-context handling, such as gpt-4o or claude-3-5-sonnet, because the input payload may contain hundreds of claims and sources. Enable structured output mode if available, and set a low temperature (0.0–0.2) for deterministic gap classification. Log every invocation—input payload hash, model version, output, validation result, and reviewer decision—to maintain an audit trail. Avoid wiring this prompt directly to an automated evidence re-retrieval loop without human review; a misclassified gap could trigger expensive, unnecessary retrieval or, worse, mask real coverage failures. The gap report should inform prioritization, not autonomously drive remediation.