Multi-Source Evidence Sufficiency Rubric Prompt Template

This prompt is designed for verification architects and pipeline engineers who need to score how well a collection of evidence sources supports or refutes a single, atomic claim. The core job-to-be-done is a structured, auditable sufficiency judgment that goes beyond a single-source relevance score. Use this when your pipeline has already retrieved multiple evidence items for a claim and you need to evaluate the evidence as a system, assessing completeness (do the sources cover all facets of the claim?), diversity (are the sources independent, or just an echo chamber?), and authority (is the right kind of source speaking to this specific claim domain?). The output is a rubric-based score with dimension breakdowns, which directly informs the next step in your pipeline: routing to auto-verification, queuing for human review, or flagging as unverifiable due to insufficient evidence.

You should not use this prompt for single-source relevance scoring or for making a final true/false determination on a claim. It is a sufficiency scorer, not a verdict generator. If you only have one evidence item, a simpler evidence-claim alignment prompt is more appropriate. Similarly, avoid this prompt if your claims have not yet been decomposed into atomic, verifiable units; a complex, multi-faceted claim will produce a muddy sufficiency score. This prompt also assumes that the provided evidence comes with source metadata (e.g., URL, publication date, author credentials). Without that metadata, the authority and diversity dimensions cannot be reliably scored, and the rubric will underperform.

Before wiring this into your pipeline, ensure your upstream processes are solid. The claim extraction step must produce a single, self-contained assertion. The evidence retrieval step must return a list of candidates, not just the top-1 result. A common failure mode is feeding this prompt a claim like 'The new policy will reduce emissions by 40% and create 10,000 jobs,' which contains two separate assertions. Decompose that first. Another failure mode is providing evidence items without clear source boundaries, causing the model to conflate multiple documents. Once you have clean inputs, this prompt becomes a powerful triage gate. Use its structured output to set deterministic thresholds: for example, if the overall sufficiency score is below 0.6, route to a human reviewer with the generated gap analysis. If it's above 0.85, proceed to automated verification. The next step is to copy the template, map your claim and evidence schemas to the placeholders, and run it against a golden set of 20-30 labeled examples to calibrate your routing thresholds.

This is the core prompt for the Multi-Source Evidence Sufficiency Rubric. It instructs the model to act as a verification architect, scoring a single claim against a structured rubric that weighs evidence completeness, source diversity, and authority. The output is a strict JSON object containing a final sufficiency score and a breakdown of each dimension. Copy this template directly into your verification pipeline, replacing the square-bracket placeholders with your specific claim, evidence set, and operational constraints.

textCopy
You are a verification architect evaluating the sufficiency of evidence for a single claim. Your task is to apply a multi-dimensional rubric to the provided [CLAIM] and [EVIDENCE_SET], then produce a structured JSON output.

**Rubric Dimensions:**
1.  **Evidence Completeness (0-10):** Does the evidence directly and fully address the core factual assertion of the claim? A score of 10 means the evidence leaves no reasonable gap. A score of 0 means the evidence is entirely tangential.
2.  **Source Diversity (0-10):** How many independent, non-referencing sources corroborate the claim? A score of 10 requires multiple, clearly independent confirmations. A score of 0 means only a single source is provided or all sources trace back to one origin.
3.  **Source Authority (0-10):** What is the aggregate credibility and domain relevance of the sources? Weight sources based on their expertise, official status, and recency as defined in [AUTHORITY_CRITERIA]. A score of 10 represents unimpeachable, directly relevant authorities.

**Scoring Process:**
1.  Analyze the [CLAIM] to identify its core, verifiable factual assertion.
2.  For each piece of evidence in the [EVIDENCE_SET], evaluate its relevance, independence, and source authority.
3.  Assign a score for each of the three rubric dimensions, providing a concise, evidence-based justification.
4.  Calculate the `overall_sufficiency_score` as the weighted average: `(Completeness * 0.5) + (Diversity * 0.3) + (Authority * 0.2)`. Round to one decimal place.
5.  If the `overall_sufficiency_score` falls below [TRIAGE_THRESHOLD], set the `recommended_action` to `HUMAN_REVIEW`. Otherwise, set it to `AUTO_VERIFY`.

**Constraints:**
- Do not evaluate the truth of the claim itself, only the sufficiency of the provided evidence.
- If evidence contradicts the claim, note this in the `completeness_justification` and penalize the completeness score accordingly.
- Adhere strictly to the [OUTPUT_SCHEMA].
- If the [EVIDENCE_SET] is empty, all scores must be 0.

[CLAIM]: {{claim}}
[EVIDENCE_SET]: {{evidence_set}}
[AUTHORITY_CRITERIA]: {{authority_criteria}}
[TRIAGE_THRESHOLD]: {{triage_threshold}}
[OUTPUT_SCHEMA]: {{output_schema}}

Adaptation Guide: The placeholders are designed for direct substitution by your application logic. [CLAIM] and [EVIDENCE_SET] are the primary dynamic inputs. [AUTHORITY_CRITERIA] should be a static, domain-specific string injected from your configuration (e.g., 'For medical claims, prioritize peer-reviewed journals and official health agencies.'). [TRIAGE_THRESHOLD] is a numeric value (e.g., 7.0) that controls the human-review routing decision. The [OUTPUT_SCHEMA] placeholder should be replaced with the exact JSON schema you expect, ensuring the model's output can be parsed and validated by your downstream systems. For high-stakes domains, always route HUMAN_REVIEW actions to a queue and log the full prompt and response for auditability.

This prompt is not a standalone chat interaction—it is a scoring function inside a larger verification pipeline. The typical harness calls this prompt after claim extraction and evidence retrieval have already completed. The input to this prompt is a single claim paired with a pre-assembled evidence dossier containing multiple sources. The output is a structured rubric score that downstream routing logic uses to decide whether the claim is auto-verified, escalated for human review, or rejected as unverifiable. Treat this prompt as a deterministic scorer with a structured output contract, not as an open-ended reasoning agent.

Integration pattern: Wrap the prompt in a function that accepts claim_text, evidence_list (array of objects with source_id, source_text, source_authority_tier, publication_date), and claim_domain (e.g., 'financial', 'medical', 'technical'). The function assembles the prompt, calls the model with response_format set to a JSON schema matching the rubric output fields (completeness_score, diversity_score, authority_score, overall_sufficiency, dimension_breakdown, missing_evidence_types, contradiction_flags), and returns the parsed result. Use temperature=0 for scoring consistency. For high-stakes domains, run the prompt three times and flag any claim where the overall_sufficiency tier differs across runs—this variance is itself a signal for human review.

Validation and retry logic: After parsing the JSON output, validate that all required fields are present, scores fall within expected ranges (e.g., 0.0–1.0), and the overall_sufficiency tier matches one of the defined enum values (SUFFICIENT, PARTIALLY_SUFFICIENT, INSUFFICIENT). If validation fails, retry once with the same input and an added [CONSTRAINT] note: 'Your previous output failed schema validation. Ensure all fields are present and scores are numeric values between 0.0 and 1.0.' If the retry also fails, log the raw output, flag the claim for human review, and do not retry further—malformed outputs at this stage often indicate edge-case claims that need human judgment anyway.

Routing and human review integration: Use the overall_sufficiency tier to drive triage. Claims scored SUFFICIENT with no contradiction_flags can proceed to auto-verification. Claims scored PARTIALLY_SUFFICIENT should route to a human review queue with the full rubric breakdown and evidence dossier attached. Claims scored INSUFFICIENT should be logged as unverifiable and surfaced to content owners with the missing_evidence_types list so they understand what additional sourcing would be needed. Critical rule: never treat INSUFFICIENT as 'false'—it means the system cannot determine truth value from available evidence, and presenting it as a negative finding creates a dangerous false-equivalence error.

Observability and audit trail: Log every prompt invocation with claim_id, prompt_version, model_id, input_evidence_count, output_scores, validation_status, and routing_decision. This log becomes the audit trail for any downstream confidence decision. For regulated domains, store the full prompt text and raw model response for replay-ability during audits. If you later change the rubric criteria or scoring weights, re-run a sample of previously scored claims through the new prompt version and compare score distributions to detect drift before promoting the change to production.