Evidence Sufficiency Threshold Enforcement Prompt Template

This prompt is designed for verification system architects who need to programmatically decide whether a set of evidence meets a predefined bar before a claim can be marked as VERIFIED. It acts as a configurable gatekeeper, enforcing organizational standards for corroboration count, source diversity, and evidence recency. The ideal user is an engineer or pipeline operator integrating this prompt into an automated fact-checking system, where a structured, deterministic pass/fail decision is required to prevent low-quality verifications from entering a system of record.

Use this prompt only after evidence retrieval and matching are complete. It assumes that a claim has already been paired with a set of candidate evidence objects, each containing structured metadata like a source identifier, publication date, and a relevance score. The prompt does not perform fact-checking, retrieve new evidence, or extract claims from raw text. Its sole responsibility is to apply configurable threshold rules to the provided evidence set and produce a structured verdict. A typical input is a JSON object containing the claim text and an array of matched evidence records, while the output is a strict pass/fail decision with an audit trail of which specific thresholds were violated.

Do not use this prompt as a substitute for evidence retrieval or claim extraction. If the input evidence set is incomplete or poorly matched, this prompt will correctly return a FAIL result, but it cannot diagnose why the retrieval pipeline failed. For that, use an upstream prompt like the Missing Evidence Gap Analysis Prompt Template. Similarly, this prompt should not be used to generate user-facing explanations or final verification reports; its output is a machine-readable decision meant to be consumed by downstream orchestration logic. For high-risk domains like healthcare or legal compliance, always route FAIL outcomes to a human review queue using a prompt like the Unsupported Claim Human Review Routing Prompt Template before finalizing a status.

This prompt template is the core instruction set for a verification threshold enforcer. It is designed to be dropped into your verification pipeline after claim extraction and evidence retrieval. The model receives a single claim and a structured evidence set, then applies your configured sufficiency rules to produce a deterministic pass/fail decision. The output includes a detailed audit trail documenting exactly which thresholds were met, which were violated, and why. This template assumes you have already retrieved candidate evidence; it does not perform retrieval itself.

textCopy
You are a verification threshold enforcement engine. Your job is to evaluate whether a single claim meets pre-configured evidence sufficiency requirements. You do not assess truth. You assess whether the available evidence is sufficient to mark the claim as VERIFIED according to the rules below.

## INPUT

CLAIM: [CLAIM_TEXT]

EVIDENCE_SET: [EVIDENCE_JSON_ARRAY]
Each evidence object contains:
- id: string
- source_id: string
- source_type: string (e.g., "primary_document", "news_report", "expert_testimony", "database_record")
- publication_date: ISO 8601 date string
- excerpt: string (relevant passage)
- relationship_to_claim: string ("supports", "contradicts", "mentions", "neutral")

## THRESHOLD CONFIGURATION

[CORROBORATION_THRESHOLD]: Minimum number of distinct evidence items that must support the claim.
[SOURCE_DIVERSITY_THRESHOLD]: Minimum number of distinct source_types required among supporting evidence.
[RECENCY_THRESHOLD_DAYS]: Maximum age in days for the most recent supporting evidence item. Claims with no supporting evidence newer than this threshold fail.
[REQUIRE_PRIMARY_SOURCE]: Boolean. If true, at least one supporting evidence item must have source_type "primary_document".
[CONTRADICTION_TOLERANCE]: Integer. Maximum number of contradicting evidence items allowed before the claim is automatically marked INSUFFICIENT regardless of supporting evidence count. Set to 0 for zero-tolerance.

## DECISION RULES

1. Count all evidence items where relationship_to_claim is "supports".
2. Count distinct source_types among those supporting items.
3. Identify the most recent publication_date among supporting items.
4. Check for presence of a primary source if required.
5. Count all evidence items where relationship_to_claim is "contradicts".
6. If contradiction count exceeds CONTRADICTION_TOLERANCE, return INSUFFICIENT immediately.
7. If all other thresholds are met, return SUFFICIENT. Otherwise, return INSUFFICIENT.

## OUTPUT SCHEMA

Return valid JSON only. No markdown, no commentary.

{
  "decision": "SUFFICIENT" | "INSUFFICIENT",
  "threshold_results": {
    "corroboration": {
      "required": number,
      "actual": number,
      "met": boolean
    },
    "source_diversity": {
      "required": number,
      "actual": number,
      "source_types_found": [string],
      "met": boolean
    },
    "recency": {
      "max_age_days": number,
      "most_recent_date": string | null,
      "met": boolean
    },
    "primary_source": {
      "required": boolean,
      "found": boolean,
      "met": boolean
    },
    "contradiction_check": {
      "tolerance": number,
      "contradiction_count": number,
      "met": boolean
    }
  },
  "violated_thresholds": [string],
  "audit_summary": "One-sentence summary of which thresholds passed or failed and why.",
  "evidence_summary": {
    "total_items": number,
    "supporting_count": number,
    "contradicting_count": number,
    "neutral_count": number
  }
}

## CONSTRAINTS

- Do not evaluate the truth of the claim. Only evaluate evidence sufficiency.
- Do not invent evidence. Only use the provided EVIDENCE_SET.
- If EVIDENCE_SET is empty, return INSUFFICIENT with all thresholds marked as unmet.
- If CLAIM_TEXT is empty or nonsensical, return INSUFFICIENT and note the invalid input in audit_summary.
- Always return the exact JSON schema above.

To adapt this template, replace the square-bracket placeholders with your pipeline's runtime values. [CLAIM_TEXT] should receive a single atomic claim string. [EVIDENCE_JSON_ARRAY] must be a pre-retrieved, serialized JSON array of evidence objects conforming to the schema described. The five threshold configuration placeholders should be injected from your application's configuration layer, allowing different claim types or domains to use different thresholds without changing the prompt structure. For high-stakes domains like healthcare or legal review, set CONTRADICTION_TOLERANCE to 0 and REQUIRE_PRIMARY_SOURCE to true. For news monitoring, you might allow higher tolerance and lower diversity requirements.

After pasting this prompt into your pipeline, validate the output against the JSON schema before allowing downstream consumption. A common failure mode is the model returning markdown-wrapped JSON despite the explicit constraint; implement a parser that strips markdown fences as a defensive measure. For production deployments, log every threshold_result object alongside the decision for auditability. If the decision is INSUFFICIENT, route the violated_thresholds array to your gap analysis or human review prompt. Never treat INSUFFICIENT as equivalent to false; it means the verification process could not reach a conclusion under the configured rules.

This prompt is designed to be a deterministic gate in a verification pipeline, not a conversational assistant. It should be called after claim extraction and evidence retrieval are complete, receiving a structured payload of a single claim and its associated evidence set. The application layer is responsible for assembling the [CLAIM], [EVIDENCE_SET], and [THRESHOLD_CONFIG] variables before invoking the model. Because the output is a pass/fail decision with specific threshold violations, the harness must treat any response that does not conform to the expected schema as a system error requiring retry or escalation.

Validation and retry logic is critical here. Implement a strict JSON schema validator that checks for the required fields: threshold_result (PASS/FAIL), violations (array of objects with threshold_name, requirement, actual, and evidence_gap), and audit_summary. If the model returns malformed JSON, missing fields, or a threshold_result that is not PASS or FAIL, retry once with a repair prompt that includes the validation error message. If the second attempt also fails, route the claim to a human review queue with the raw evidence attached. Do not silently default to PASS or FAIL on parse errors—this creates a dangerous blind spot in the verification pipeline.

Model choice and latency budgeting matter here. This is a classification and structured output task that does not require creative generation, so a smaller, faster model (e.g., GPT-4o-mini, Claude Haiku) is often sufficient. However, if your threshold config includes complex reasoning requirements like 'source diversity across independent organizations' or 'recency within a sliding window,' test whether the smaller model correctly applies those rules before deploying. For high-stakes domains like healthcare or legal verification, use a more capable model and always include a human review step for FAIL outcomes. Log every invocation with the claim ID, threshold config version, model response, validation result, and final routing decision for audit trail generation.

Tool integration is typically not needed for this prompt itself, but the upstream evidence retrieval step often uses search tools or RAG. Ensure the [EVIDENCE_SET] passed to this prompt includes source metadata (title, date, authority score) so the model can evaluate recency and source diversity thresholds. If your threshold config requires corroboration count, pre-count the number of distinct sources and include that as a field in the evidence set to reduce model counting errors. For production pipelines processing high volumes, batch claims with similar threshold configs together and use prompt caching on the system instructions and threshold config portion to reduce cost and latency.