Unsupported Claim Disclosure Report Prompt

This prompt is designed for verification pipeline operators who need to systematically identify and report claims that lack sufficient supporting evidence within a given source set. The primary job-to-be-done is generating a structured disclosure report that distinguishes between claims that are proven false and claims that simply cannot be verified with the available information. This distinction is critical for compliance, audit, and governance workflows where a false positive (labeling a true claim as unsupported) can be as damaging as a false negative (failing to flag a truly unsupported claim). The ideal user is an engineer or technical operator integrating this prompt into an automated fact-checking pipeline, not an end-user running one-off queries.

Use this prompt when you have already completed claim extraction and evidence matching steps in your pipeline. The input should be a structured list of claims paired with their retrieved evidence sets, not raw documents. The prompt expects to receive claim text, available evidence summaries, source identifiers, and any preliminary match scores. It is specifically designed for batch processing multiple claims in a single request to optimize throughput and cost. Do not use this prompt for real-time, single-claim verification where latency is the primary concern, or for scenarios where the evidence retrieval step has not yet been performed. The prompt assumes evidence has already been gathered and needs assessment, not discovery.

Before deploying this prompt, ensure your pipeline has clear thresholds for what constitutes 'sufficient evidence.' The prompt template includes a [SUFFICIENCY_THRESHOLD] placeholder that should be calibrated to your domain's risk tolerance. For regulated domains like healthcare or finance, set this threshold conservatively and always route outputs through human review before final disclosure. The prompt includes built-in false-positive and false-negative detection logic, but these checks are probabilistic—they reduce risk, they do not eliminate it. Pair this prompt with the Evidence Sufficiency Assessment Report Prompt for deeper gap analysis on flagged claims, and always log outputs to your audit trail for traceability.

This prompt template is the core instruction set for generating a structured disclosure report that flags claims lacking sufficient evidence. It is designed to be dropped into a verification pipeline after claim extraction and evidence matching have completed. The template uses square-bracket placeholders so you can wire in dynamic inputs—such as the list of claims, the evidence pool, and your organization's evidence-sufficiency thresholds—without rewriting the core logic each time. The output is a strict JSON report that separates unsupported claims from those with adequate evidence, documents the specific gaps, and summarizes the search coverage, making it ready for downstream logging, human review routing, or audit packaging.

Below is the copy-ready prompt template. Copy it into your prompt management system, replace the placeholders with your pipeline's runtime values, and pair it with a JSON schema validator in your application layer. The [CONSTRAINTS] placeholder is where you inject domain-specific rules, such as regulatory evidence standards or mandatory source types. The [RISK_LEVEL] placeholder controls the strictness of the classification threshold, which directly affects false-positive and false-negative rates for unsupported classifications.

textCopy
You are a verification disclosure analyst. Your task is to produce an Unsupported Claim Disclosure Report from a set of extracted claims and available evidence.

## INPUT
- Claims: [CLAIMS_LIST]
- Evidence Pool: [EVIDENCE_POOL]
- Evidence Sufficiency Threshold: [SUFFICIENCY_THRESHOLD]
- Search Coverage Summary: [SEARCH_COVERAGE]

## CONSTRAINTS
[CONSTRAINTS]

## TASK
For each claim in [CLAIMS_LIST], determine whether the available evidence in [EVIDENCE_POOL] meets the sufficiency threshold defined in [SUFFICIENCY_THRESHOLD]. A claim is UNSUPPORTED if the evidence does not reach this threshold. A claim is SUPPORTED if the evidence meets or exceeds the threshold.

For each UNSUPPORTED claim, document:
- The specific evidence gap (what is missing)
- Which sources were consulted and why they were insufficient
- Whether the gap is due to missing sources, low-quality sources, or contradictory evidence

## OUTPUT_SCHEMA
Return a valid JSON object with this exact structure:
{
  "report_id": "string",
  "generated_at": "ISO8601 timestamp",
  "threshold_applied": "string",
  "summary": {
    "total_claims": integer,
    "supported_claims": integer,
    "unsupported_claims": integer,
    "search_coverage_notes": "string"
  },
  "unsupported_claims": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "gap_type": "missing_source|insufficient_quality|contradictory_evidence|no_evidence_found",
      "gap_description": "string",
      "sources_consulted": ["string"],
      "insufficiency_rationale": "string"
    }
  ],
  "supported_claims_summary": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "primary_supporting_source": "string"
    }
  ],
  "false_negative_risk_notes": "string",
  "false_positive_risk_notes": "string"
}

## RISK_LEVEL
[RISK_LEVEL]

## INSTRUCTIONS
- Do not classify a claim as false; only classify it as supported or unsupported based on evidence availability.
- If evidence is contradictory, classify the claim as unsupported with gap_type "contradictory_evidence" and explain the conflict.
- Include the false_negative_risk_notes field to describe any claims that might be supported but were classified as unsupported due to strict thresholding.
- Include the false_positive_risk_notes field to describe any claims that might be unsupported but were classified as supported due to weak or circumstantial evidence.
- If [SEARCH_COVERAGE] indicates that certain sources or domains were not searched, reflect this limitation in search_coverage_notes.

To adapt this template for your pipeline, start by defining [SUFFICIENCY_THRESHOLD] as a concrete, machine-readable rule—for example, "at least two authoritative sources with direct corroboration" or "one primary source with explicit quote match." Vague thresholds produce inconsistent classifications. Next, populate [CONSTRAINTS] with domain-specific evidence rules, such as "medical claims require peer-reviewed sources published within the last 5 years" or "financial claims require audited filings." The [RISK_LEVEL] field should map to your operational tolerance: use "high" to minimize false positives (fewer claims flagged, higher risk of missing unsupported statements) or "low" to minimize false negatives (more claims flagged, higher review volume). After generating the report, always validate the JSON output against the schema and run your eval suite to check for missing gap_descriptions, misclassified gap_types, and incomplete sources_consulted arrays before the report enters an audit trail or human review queue.

The Unsupported Claim Disclosure Report prompt is designed to be a critical safety net in an automated fact-checking pipeline. It should be invoked after claim extraction and evidence matching have been completed, but before any final verdict is published. The primary input to this prompt is a structured list of claims paired with their associated evidence retrieval results. The application layer must assemble this context carefully, ensuring that each claim is presented with the full set of evidence snippets, source metadata, and search queries that were executed. The prompt's job is not to re-evaluate the evidence, but to audit the evidence coverage and flag claims where the available information is insufficient to support a confident true/false determination.

To integrate this into an application, wrap the prompt call in a function that accepts a batch of VerificationCandidate objects. Each object must contain the original claim text, a list of retrieved evidence passages with their source URIs and relevance scores, and the search queries used. The function should construct the prompt by serializing this data into the [CLAIMS_AND_EVIDENCE] placeholder. After receiving the model's response, a strict JSON schema validator must confirm the output matches the expected structure: a list of unsupported claims, each with a gap_description, search_coverage_summary, and a recommended_action. Any output that fails schema validation should trigger a single retry with a more forceful instruction to adhere to the output format. If the retry also fails, the batch must be routed to a human review queue with the raw model output attached for diagnosis.

For high-stakes domains like healthcare or finance, implement a false-negative detection layer immediately after this prompt. This is a separate evaluator prompt or heuristic check that samples a subset of claims the model did not flag as unsupported and asks a more capable model, 'Is there truly sufficient evidence for this claim?' This helps catch cases where the primary prompt missed a gap. Log every invocation with the full prompt, the model's response, the validator result, and the final disposition (published, flagged, or escalated). This audit trail is essential for governance and for debugging prompt drift over time. Avoid using this prompt on its own without the upstream evidence retrieval context; without it, the model will hallucinate a plausible but fictional search coverage summary.