Verification Pipeline Null Handling Prompt Template

This prompt is for platform engineers building automated verification pipelines that must handle missing evidence gracefully. When a claim enters the pipeline and the evidence retrieval step returns zero results, an empty source set, or results too weak to evaluate, the pipeline must not crash, silently skip the claim, or fabricate a verdict. This prompt produces a structured null result with a clear status code, fallback routing instructions, and error recovery metadata. Use it as the catch-all handler at the end of your evidence retrieval step, before the verification scoring step. It assumes you have already attempted retrieval and have a set of sources to evaluate, even if that set is empty or insufficient.

The ideal user is a verification pipeline operator or platform engineer who has already built the retrieval and scoring stages and now needs to close the gap where evidence simply doesn't exist. The required context includes the original claim text, the retrieval query used, the list of sources returned (or an empty array), and any retrieval metadata such as search duration or index scope. Without this context, the prompt cannot produce a meaningful null result because it cannot distinguish between 'we didn't look' and 'we looked and found nothing.' The output must include a machine-readable status field, a human-readable explanation, and routing instructions that downstream orchestration logic can act on without additional parsing.

Do not use this prompt when evidence exists but is contradictory, low-quality, or outdated. Those conditions require the Evidence Sufficiency Threshold Enforcement or Contradiction Detection prompts, which produce scored verdicts rather than null declarations. Do not use this prompt as a substitute for proper error handling in your retrieval code—if the retrieval API itself fails with a 5xx error, that's an infrastructure problem, not a null-evidence problem. This prompt is specifically for the case where retrieval succeeds but returns nothing useful. Wire it into your pipeline as the final step in the evidence retrieval stage, with a conditional gate that routes to this prompt only when the source set is empty or below a minimum quality threshold you define upstream.

Before deploying, test this prompt against three scenarios: an empty source array, a source array containing only irrelevant documents, and a source array where the retrieval system returned an error message instead of documents. Each scenario should produce a distinct but consistently structured output. If your pipeline cannot distinguish between these cases in its routing logic, add a pre-processing step that normalizes the retrieval result before it reaches this prompt. The next section provides the exact template and placeholders you'll need to implement this handler.

This prompt is the null-handling step in a verification pipeline. It expects a single claim and an array of sources, and its only job is to determine whether the available evidence is sufficient to proceed. If evidence is missing, contradictory, or too weak, the prompt returns a structured null result with a reason code and fallback routing instructions. This prevents the pipeline from treating 'no evidence' as 'false' or from passing a claim to a downstream verifier that will hallucinate a confidence score. Wire this prompt immediately after evidence retrieval and before any claim-verdict prompt.

textCopy
You are a verification pipeline guard. Your only task is to decide whether the provided sources contain enough evidence to attempt verification of the claim. You do not verify the claim. You only assess evidence sufficiency.

INPUT:
- Claim: [CLAIM_TEXT]
- Sources: [SOURCES_ARRAY]
- Minimum Evidence Threshold: [MIN_THRESHOLD_CONFIG]

SOURCES_ARRAY format: Each source object has `id`, `text`, `date`, and `authority` fields.

MIN_THRESHOLD_CONFIG format:
- `min_corroborating_sources`: integer (default 1)
- `require_recent`: boolean (default false)
- `min_authority_level`: string ("low" | "medium" | "high")

RULES:
1. If zero sources contain information relevant to the claim, return NULL_EVIDENCE.
2. If sources exist but none directly address the claim's core assertion, return NULL_EVIDENCE.
3. If sources address the claim but fall below the minimum evidence threshold, return INSUFFICIENT_EVIDENCE with a list of specific threshold violations.
4. If sources are contradictory and no clear preponderance exists, return CONTRADICTORY_EVIDENCE.
5. Only return SUFFICIENT_EVIDENCE if the threshold is met and sources are consistent.

OUTPUT_SCHEMA (strict JSON):
{
  "status": "SUFFICIENT_EVIDENCE" | "NULL_EVIDENCE" | "INSUFFICIENT_EVIDENCE" | "CONTRADICTORY_EVIDENCE",
  "claim_id": "string",
  "evidence_summary": {
    "relevant_source_count": integer,
    "corroborating_source_count": integer,
    "contradicting_source_count": integer,
    "best_source_id": "string | null",
    "best_source_authority": "string | null"
  },
  "threshold_violations": [
    {
      "rule": "string",
      "expected": "string",
      "actual": "string"
    }
  ],
  "fallback_action": "PROCEED_TO_VERIFICATION" | "ROUTE_TO_HUMAN_REVIEW" | "FLAG_AS_UNVERIFIABLE" | "REQUEST_ADDITIONAL_SOURCES",
  "fallback_rationale": "string"
}

CONSTRAINTS:
- Never return a verification verdict (true/false/supported/refuted).
- Never invent evidence or sources.
- If the claim references a document section not present in sources, treat as NULL_EVIDENCE.
- If sources are present but irrelevant, explain why they don't match.
- Always include specific threshold violations when returning INSUFFICIENT_EVIDENCE.

Adapt this template by adjusting MIN_THRESHOLD_CONFIG to match your domain's evidence standards. For legal claims, set min_corroborating_sources to 2 and min_authority_level to "high." For news verification, set require_recent to true and add a max_source_age_days field. For internal knowledge base checks, you may lower the threshold to 1 and remove the authority requirement. The fallback_action field should map to your pipeline's actual routing logic: a queue name, a webhook, or a status flag in your verification database. Test this prompt with edge cases including empty source arrays, sources in a different language, sources that mention the topic but not the specific claim, and claims that require numerical evidence when only textual sources are provided.

The Verification Pipeline Null Handling Prompt Template is designed as a safety net within a broader verification orchestration system. It should not be the primary prompt for claim verification. Instead, it acts as a catch-all when an upstream verification step fails to produce a valid structured output, returns a null or empty result, or throws an exception. The harness must intercept these failure states and route them to this prompt, providing the original claim, the failed step's context, and the raw error or empty response. This ensures that a pipeline failure does not result in a silent null, which could be misinterpreted as a negative verification result downstream.

To wire this into an application, implement a validation layer immediately after every model call in your verification pipeline. This layer should check for a valid JSON structure, the presence of required fields like verdict or status, and non-null values for critical fields. If validation fails, the harness should construct a new request using this Null Handling Prompt Template, populating the [ORIGINAL_CLAIM], [FAILED_PIPELINE_STEP], and [RAW_ERROR_CONTEXT] placeholders. The model should be instructed to produce a structured null_result object with a fallback_routing field (e.g., HUMAN_REVIEW, RETRY_WITH_EXPANDED_SOURCES, MARK_UNVERIFIABLE). The application must then parse this output and execute the specified routing logic, such as placing the claim into a review queue or triggering a search for additional evidence. Log every instance of this fallback being triggered, including the raw error and the model's routing decision, to create an audit trail and identify systemic pipeline weaknesses.

For high-stakes verification domains, never allow the system to automatically mark a claim as 'unverified' or 'false' based on a pipeline error. The harness must enforce a human review step for any claim routed to HUMAN_REVIEW by this prompt. Implement a retry budget: if the null-handling prompt itself fails validation, retry once with a lower temperature setting. If it fails again, escalate the entire claim payload to an operations alerting channel and log the failure as a critical incident. Model choice matters here; use a highly reliable, instruction-following model with strong JSON mode capabilities for this recovery step, as it must produce a predictable routing decision under degraded conditions. Avoid using a smaller, faster model for this task, as the cost of a misrouted null result is far higher than the latency or token cost of a more capable model.