Claim Complexity Scoring for Triage Prompt

This prompt is designed for verification pipeline operators and platform engineers who need to estimate the difficulty of verifying a claim before routing it to an automated system or a human reviewer. It produces a structured complexity score that considers claim structure, domain specificity, evidence requirements, and ambiguity. Use this prompt when your triage system must decide how to allocate verification resources, predict reviewer time-to-resolve, or set confidence thresholds for auto-verification.

The output is a pre-verification assessment, not a final verdict. It is most valuable when you need to calibrate routing logic, balance reviewer workloads, or measure whether your complexity estimates correlate with actual resolution effort. For example, you might use it to sort a batch of 500 extracted claims so that high-complexity items are routed to senior reviewers while low-complexity, high-confidence claims are sent to an auto-verification pipeline. The prompt expects a single claim and its surrounding context as input, and it returns a score with contributing factors.

Do not use this prompt for the final verification verdict itself. It does not determine truth or falsehood, and it should not be the sole gate for publishing, blocking, or removing content. Avoid using it on claims that are already fully verified or on claims where the evidence set is complete and a direct match is trivial. If your pipeline already has a deterministic complexity heuristic based on claim length or source count, this prompt may add latency without benefit. Start by running this prompt on a labeled calibration set to validate that its complexity scores correlate with your actual reviewer time-to-resolve before deploying it in a live routing path.

This prompt template is designed to be dropped directly into your verification pipeline. It instructs the model to act as a verification triage analyst, scoring a claim's complexity based on its structure, domain, and evidence requirements. The output is a structured JSON object that your application can parse to route the claim to an auto-verification module, a domain expert, or a human review queue. Before using this in production, you must calibrate the scoring thresholds against your actual reviewer time-to-resolve data to ensure the scores correlate with real-world effort.

textCopy
You are a verification triage analyst. Your task is to estimate the complexity of verifying a factual claim. This score will be used to route the claim to an automated system, a domain expert, or a human reviewer.

INPUT CLAIM:
[CLAIM_TEXT]

AVAILABLE CONTEXT (Optional):
[CONTEXT]

ANALYSIS INSTRUCTIONS:
Evaluate the claim on the following four dimensions, each on a scale of 1 (simple) to 5 (highly complex):
1.  **Structural Complexity:** Is the claim atomic, or does it contain multiple nested assertions, comparisons, or conditional statements?
2.  **Domain Specificity:** Does the claim require specialized knowledge (e.g., legal, medical, financial) or is it general knowledge?
3.  **Evidence Accessibility:** How difficult is it to find a definitive, authoritative source to prove or disprove this claim? Consider if the evidence is likely public, proprietary, or experiential.
4.  **Ambiguity Level:** How vague or subjective is the claim's language? Are there quantifiable terms, or is it open to interpretation?

OUTPUT SCHEMA:
You must respond with a single, valid JSON object conforming to this structure:
{
  "claim_summary": "A concise re-statement of the core claim being evaluated.",
  "complexity_score": "An integer from 4 to 20, representing the sum of the four dimension scores.",
  "score_breakdown": {
    "structural_complexity": "Integer 1-5 with a one-sentence justification.",
    "domain_specificity": "Integer 1-5 with a one-sentence justification.",
    "evidence_accessibility": "Integer 1-5 with a one-sentence justification.",
    "ambiguity_level": "Integer 1-5 with a one-sentence justification."
  },
  "recommended_routing": "A suggestion of 'auto_verify', 'expert_review', or 'human_review' based on the score and breakdown.",
  "routing_rationale": "A brief explanation connecting the complexity score to the routing recommendation."
}

CONSTRAINTS:
- Do not attempt to verify the claim. Only score its complexity.
- If the claim is unintelligible, set all scores to 5 and the routing to 'human_review'.
- Base your assessment only on the provided claim and context.

To adapt this template, start by tuning the four complexity dimensions. Your domain might require different axes, such as 'Temporal Sensitivity' for news or 'Numerical Density' for financial claims. The critical calibration step is to run a batch of historical claims through this prompt and compare the complexity_score and recommended_routing against the actual time and expertise required to resolve them. Adjust the scoring scales and routing thresholds until the prompt's output is a reliable predictor of your operational costs. For high-stakes domains, always add a step for human approval on routing decisions that fall near a threshold boundary.

The Claim Complexity Scoring prompt is not a standalone tool—it is a triage gate that determines routing, cost, and latency for downstream verification. Wire it into your pipeline immediately after claim extraction and before any evidence retrieval or human assignment. The prompt output must be treated as a structured signal that feeds a deterministic router, not as a final decision. Store the raw score, the factor breakdown, and the model version with every claim so you can recalibrate thresholds without replaying the entire pipeline.

Build a thin validation layer around the prompt response before routing. Check that the output contains a numeric complexity score within the expected range (e.g., 1–10), that required sub-scores are present (domain specificity, evidence accessibility, ambiguity level, multi-hop requirements), and that the justification field is non-empty. If validation fails, retry once with the same prompt and a stronger format reminder. If the second attempt also fails, route the claim to a human review queue with a validation_failure flag rather than guessing. Log every validation failure for later prompt refinement. For model selection, use a fast, cost-efficient model (such as GPT-4o-mini or Claude Haiku) for this triage step—the goal is low latency and low cost per claim, since this gate runs on every incoming claim before expensive retrieval or human review.

Calibration is the hardest part of this harness. You must measure whether the complexity scores actually correlate with reviewer time-to-resolve, error rates, or verification cost. Instrument your pipeline to capture the complexity score at triage time and the actual resolution metrics (reviewer minutes, number of evidence sources consulted, correctness outcome) at completion. Run a weekly calibration check: if claims scored 1–3 are taking longer than expected or claims scored 8–10 are resolving quickly, your thresholds or the prompt itself need adjustment. Publish a calibration dashboard that tracks score-vs-outcome correlation and flags drift. For high-stakes domains, add a human-in-the-loop sampling rule: every N claims in each complexity bucket get a full manual review regardless of score, so you can detect silent calibration failures before they cause systematic routing errors.

Avoid routing claims directly from the complexity score without a cost-latency budget check. Even if a claim scores low complexity, if your auto-verification pipeline is overloaded or the evidence retrieval latency exceeds your SLA, you may need to route to human review anyway. Implement a circuit breaker: if auto-verification queue depth exceeds a threshold, temporarily route all claims above a minimum complexity to human review to prevent SLA breaches. The complexity score feeds this decision but does not own it. Finally, never expose the raw complexity score to end users or downstream consumers without context—a 'complexity 7' means nothing to a reviewer. Instead, translate it into actionable routing labels like 'standard review,' 'specialist required,' or 'multi-source investigation needed' based on your calibrated thresholds.