Evidence Matching with Null Evidence Handling Prompt

This prompt is designed for verification pipeline operators and RAG system builders who must handle empty retrieval results gracefully. In production systems, a search for supporting evidence can return zero documents, yet standard evidence-matching prompts often fabricate support when given empty context—producing hallucinated citations, invented quotes, or overconfident confirmations. This prompt explicitly instructs the model to detect null evidence conditions, produce a structured 'no evidence found' output, document the search query that failed, and suggest alternative queries for downstream retry logic. The primary job-to-be-done is preventing silent failures in automated verification pipelines where a missing result could otherwise be misinterpreted as a positive match.

The ideal user is a developer or pipeline operator integrating this prompt into a retrieval-augmented verification system. Required context includes the original claim being verified, the search query that was executed, and the empty or insufficient result set. You should not use this prompt when you already have evidence to evaluate—standard evidence-matching prompts handle that case. You should also avoid this prompt when the retrieval system itself is unreliable or when the cost of a false negative (missing real evidence) is higher than the cost of a false positive (hallucinated match). In high-stakes domains such as healthcare, legal, or financial verification, always route null-evidence outputs to human review rather than treating them as definitive negative findings.

Before deploying this prompt, ensure your retrieval pipeline can reliably distinguish between 'no results found' and 'results found but filtered out by relevance thresholds.' The prompt expects an explicit empty-context signal—passing near-empty or low-quality results as if they were null will produce misleading outputs. Wire this prompt into your application with a pre-check: if the retriever returns zero results or all results fall below your relevance threshold, invoke this prompt; otherwise, use your standard evidence-matching prompt. Log every null-evidence invocation with the original claim, the failed query, and the suggested alternatives to build a query-improvement feedback loop over time.

This template is designed for automated fact-checking and RAG verification pipelines where the retrieval step may return zero results. Unlike standard evidence-matching prompts that assume evidence exists, this template requires the model to explicitly document when no evidence is found, including the search queries used and suggested alternative queries. This prevents the model from hallucinating evidence or silently marking claims as unverified without explanation. Use this template when you need auditable, traceable null-evidence handling in production systems.

textCopy
You are an evidence matching system. Your task is to match each provided claim against the provided evidence set and produce a structured output. If no evidence is found for a claim, you must explicitly document this rather than remaining silent.

## INPUT

**Claims to verify:**
[CLAIMS]

**Evidence set:**
[EVIDENCE]

**Search queries used to retrieve evidence:**
[SEARCH_QUERIES]

## OUTPUT SCHEMA

Return a JSON object with the following structure:

```json
{
  "claim_matches": [
    {
      "claim_id": "string",
      "claim_text": "string",
      "match_status": "supported | contradicted | insufficient | no_evidence_found",
      "matched_evidence": [
        {
          "evidence_id": "string",
          "evidence_text": "string",
          "relevance_score": 0.0-1.0,
          "match_type": "direct_quote | paraphrase | inference",
          "relationship": "supports | contradicts | partially_supports"
        }
      ],
      "null_evidence_handling": {
        "is_null_result": true/false,
        "search_queries_used": ["string"],
        "reason_no_evidence": "no_results_returned | results_irrelevant | insufficient_coverage",
        "suggested_alternative_queries": ["string"],
        "evidence_gap_description": "string"
      },
      "confidence": 0.0-1.0,
      "requires_human_review": true/false
    }
  ],
  "summary": {
    "total_claims": 0,
    "supported": 0,
    "contradicted": 0,
    "insufficient": 0,
    "no_evidence_found": 0,
    "null_result_rate": 0.0
  }
}

CONSTRAINTS

1. Null evidence is a valid output. If the evidence set is empty or contains no relevant passages, set match_status to no_evidence_found and populate the null_evidence_handling block completely.
2. Document search queries. Always include the search queries that were used. If none were provided, note this in reason_no_evidence.
3. Suggest alternatives. When no evidence is found, propose at least one alternative search query that might surface relevant evidence.
4. Never fabricate evidence. If you cannot find supporting or contradicting evidence, do not invent it. Use the no_evidence_found status.
5. Distinguish insufficient from no evidence. Use insufficient when evidence exists but is too weak, partial, or ambiguous to confirm or refute the claim. Use no_evidence_found when the evidence set contains nothing relevant.
6. Flag for human review when confidence is below [CONFIDENCE_THRESHOLD] or when claims are high-risk per [RISK_LEVEL].
7. Preserve claim IDs. Match the claim_id exactly as provided in the input.

EXAMPLES

Example 1: Evidence found Input claim: "The company reported $2.3B in revenue for Q3 2024." Evidence: "Q3 2024 earnings release shows total revenue of $2.3 billion, up 12% YoY." Output: match_status: "supported", matched_evidence with direct_quote, confidence: 0.95

Example 2: No evidence found Input claim: "The CEO announced a new AI division in January 2025." Evidence: [empty set] Search queries used: ["CEO AI division announcement January 2025", "new AI division company name 2025"] Output: match_status: "no_evidence_found", null_evidence_handling.is_null_result: true, suggested_alternative_queries: ["company name AI division press release 2025", "CEO strategic initiatives 2025"]

Example 3: Insufficient evidence Input claim: "The product launch will increase market share by 15%." Evidence: "Company press release mentions product launch planned for Q2 but does not include market share projections." Output: match_status: "insufficient", confidence: 0.2, requires_human_review: true

Before deploying this template, replace the square-bracket placeholders with your actual data. [CLAIMS] should be a JSON array of claim objects with claim_id and claim_text fields. [EVIDENCE] should be a JSON array of evidence objects with evidence_id and evidence_text fields. [SEARCH_QUERIES] should be an array of strings representing the queries used to retrieve the evidence. Set [CONFIDENCE_THRESHOLD] to a numeric value between 0 and 1 (e.g., 0.7) below which claims are flagged for human review. Set [RISK_LEVEL] to low, medium, or high to adjust the sensitivity of the human review flagging. For high-risk domains such as healthcare, legal, or financial verification, always require human review for no_evidence_found and insufficient statuses regardless of confidence score.

After adapting the template, validate the output against the JSON schema before allowing it to proceed downstream. Common failure modes include the model omitting the null_evidence_handling block when evidence is missing, fabricating plausible-sounding evidence when the evidence set is empty, or conflating insufficient with no_evidence_found. Run eval tests with deliberately empty evidence sets to confirm the model produces explicit null-evidence outputs rather than hallucinating. For production pipelines, log every instance where null_evidence_handling.is_null_result is true and monitor the null_result_rate in the summary to detect retrieval failures early.

This prompt is designed for a critical failure mode in automated RAG and fact-checking pipelines: the silent empty result. When a retrieval step returns zero documents, many prompts will hallucinate evidence or produce a generic 'I don't know' without documenting the failed query. This harness ensures that null-evidence states are captured as structured, auditable outputs that downstream systems can act on—whether that means escalating for human review, triggering alternative retrieval strategies, or logging the gap for index improvement.

To wire this prompt into an application, place it immediately after a retrieval step that may return an empty result set. The application should check the number of retrieved documents or the search API response code. If the count is zero, inject the original query into the [SEARCH_QUERY] placeholder and the claim into [CLAIM]. The [RETRIEVAL_SOURCE] field should identify which index, database, or API was queried. The model should be instructed to return a strict JSON schema with fields for evidence_status (must be no_evidence_found), search_query_documentation, and suggested_alternative_queries. Validate the output against this schema immediately. If evidence_status is anything other than no_evidence_found, treat it as a hallucination and retry with a stronger constraint in the system prompt, or escalate to a human operator. Log every null-evidence event with the query, the source, the timestamp, and the suggested alternatives for later retrieval pipeline analysis.

Model choice matters here. Use a model with strong instruction-following for structured output, such as GPT-4o, Claude 3.5 Sonnet, or a fine-tuned variant. Avoid smaller models that may ignore the null-evidence constraint and confabulate a match. Set temperature to 0 for deterministic behavior. Implement a retry budget of no more than 2 attempts; if the model still fails to produce a valid no_evidence_found status, route the claim to a human review queue with the full context. For high-stakes domains like healthcare or legal review, always require human sign-off on null-evidence findings before they are used to update a knowledge base or close a verification task. Wire the suggested_alternative_queries output directly into a secondary retrieval step to attempt evidence discovery through reformulated searches before finalizing the null result.