Verification Triage Priority Scoring Prompt Template

This prompt is built for verification operations teams that must allocate scarce human review capacity across a backlog of claims. The job-to-be-done is not scoring a single claim in isolation—it is producing a priority score that combines confidence urgency (how likely the claim is wrong), claim impact (what breaks if it is wrong), and verification cost (how much effort it takes to check). Use this when you have more claims than reviewers, when different claims carry different business risk, and when you need a defensible, repeatable triage order rather than an ad-hoc queue.

The ideal user is a verification pipeline operator or product manager who already has claim confidence scores, evidence sufficiency signals, or contradiction flags from upstream scoring prompts. This prompt consumes those signals as [INPUT] and adds the operational layer: impact severity, cost estimates, and deadline pressure. Do not use this prompt when you are still building the initial claim extraction or evidence matching pipeline—it assumes scored claims exist. Do not use it for binary true/false verdicts. Do not use it when every claim has equal priority and a simple FIFO queue suffices. The prompt is designed for resource-constrained triage, not for general claim evaluation.

Before wiring this into production, define your impact taxonomy and cost tiers explicitly. The prompt expects [IMPACT_LEVELS] and [COST_TIERS] as structured inputs so it can produce calibrated scores rather than vague 'high/medium/low' labels. If your team cannot yet quantify what 'high impact' means in business terms—revenue at risk, regulatory exposure, user harm potential—start there. The prompt will expose gaps in your operational definitions. Once those are clear, this playbook helps you turn a backlog of uncertain claims into an ordered, auditable verification queue with explicit reasons for every priority decision.

This prompt template is designed to be dropped into a verification pipeline where operations teams must decide which claims to verify first when resources are limited. It produces a structured priority score by combining confidence urgency, claim impact, and verification cost. The template uses square-bracket placeholders for all dynamic inputs, making it straightforward to integrate with your existing claim queue, evidence store, and business rules engine.

textCopy
You are a verification triage specialist. Your task is to assign a priority score to a claim that is waiting for verification, given limited resources. Use the inputs provided to weigh urgency, impact, and cost.

## INPUTS
- Claim: [CLAIM_TEXT]
- Claim Context: [CLAIM_CONTEXT]
- Current Confidence Score: [CONFIDENCE_SCORE]
- Confidence Urgency (why this needs verification now): [URGENCY_NOTE]
- Claim Impact (business/editorial/safety impact if wrong): [IMPACT_DESCRIPTION]
- Estimated Verification Cost (effort, time, tooling): [COST_ESTIMATE]
- Available Evidence Summary: [EVIDENCE_SUMMARY]
- Business Outcome Weighting: [BUSINESS_WEIGHT]
- Triage Rules: [TRIAGE_RULES]

## OUTPUT SCHEMA
Return a single JSON object with the following fields:
{
  "priority_score": <integer 1-100, where 100 is highest priority>,
  "score_breakdown": {
    "urgency_component": <integer 1-100>,
    "impact_component": <integer 1-100>,
    "cost_component": <integer 1-100, inverted so lower cost = higher score>,
    "business_weight_multiplier": <float>
  },
  "triage_category": "<IMMEDIATE | HIGH | STANDARD | LOW | DEFER>",
  "rationale": "<2-3 sentence explanation of the score>"
}

## CONSTRAINTS
- Do not invent evidence not present in the Available Evidence Summary.
- If the Current Confidence Score is already above 90, the priority_score must not exceed 30 unless the Claim Impact is explicitly marked as CRITICAL.
- If the Estimated Verification Cost is UNKNOWN, default the cost_component to 50.
- Apply the Business Outcome Weighting as a multiplier to the raw urgency+impact average.
- If the claim contains unverifiable opinions or future predictions, set triage_category to DEFER and priority_score to 0.

## EXAMPLES
Example 1:
Claim: "Our Q3 revenue grew 15% year-over-year."
Confidence: 45
Urgency: Earnings call in 2 days
Impact: HIGH (investor-facing)
Cost: LOW (internal data check)
Business Weight: 1.5
Output: {"priority_score": 85, "score_breakdown": {"urgency_component": 90, "impact_component": 80, "cost_component": 70, "business_weight_multiplier": 1.5}, "triage_category": "IMMEDIATE", "rationale": "High urgency due to upcoming earnings call, high impact on investor communications, and low verification cost. Business weighting increases priority."}

Example 2:
Claim: "This is the best coffee in the neighborhood."
Confidence: 60
Urgency: None
Impact: LOW
Cost: HIGH (subjective, requires survey)
Business Weight: 0.5
Output: {"priority_score": 10, "score_breakdown": {"urgency_component": 10, "impact_component": 10, "cost_component": 20, "business_weight_multiplier": 0.5}, "triage_category": "DEFER", "rationale": "Subjective claim with low business impact and high verification cost. Business weighting deprioritizes further."}

## RISK LEVEL
[HIGH_RISK_FLAG]

If HIGH_RISK_FLAG is true, append this instruction: "This claim has been flagged as high-risk. Your rationale must explicitly state whether human review is required before publication, and the priority_score must be at least 70 unless the claim is unverifiable."

To adapt this template, replace each square-bracket placeholder with data from your verification queue and business logic layer. The TRIAGE_RULES placeholder is where you inject organization-specific policies, such as regulatory review requirements or SLAs. The HIGH_RISK_FLAG is a boolean you should set in your application code before rendering the prompt; when true, it activates additional safety instructions. After generating a priority score, always validate the output JSON against the schema and check that the priority_score falls within the 0-100 range. For high-stakes domains, route any claim scored as IMMEDIATE or HIGH to a human reviewer with the full score breakdown attached.

This prompt is designed to sit inside a verification pipeline's triage layer, not as a standalone chat interaction. It should be called after claim extraction and evidence retrieval but before any human review assignment. The application layer is responsible for assembling the [CLAIM], [EVIDENCE_SUMMARY], [CONFIDENCE_SCORE], [CLAIM_IMPACT], and [VERIFICATION_COST_ESTIMATE] fields from upstream systems. The model's job is strictly to produce a structured priority score and justification—it should not retrieve evidence, extract claims, or make routing decisions on its own.

Integration pattern: Wrap this prompt in a stateless function that accepts pre-processed claim objects and returns a priority payload. Validate the output against a strict JSON schema before allowing it to influence any queue ordering. The schema must enforce priority_score as a float between 0.0 and 1.0, urgency_contribution, impact_contribution, and cost_contribution as floats that sum to approximately 1.0, and recommended_action as an enum of ["verify_immediately", "queue_for_review", "defer", "auto_dismiss"]. If validation fails, retry once with the validation error injected into the [CONSTRAINTS] field. After a second failure, log the claim for manual triage and return a default score of 0.5 with recommended_action: "queue_for_review".

Model choice and latency: Use a fast, cost-efficient model for this scoring task—GPT-4o-mini, Claude Haiku, or an equivalent small model. The prompt requires structured reasoning but not deep domain expertise. Set a strict timeout of 5 seconds per claim. If you are processing claims in batch, run scoring calls concurrently with a concurrency limit matching your API tier's rate limits. For high-throughput pipelines, consider caching scores for claims with identical evidence profiles and confidence levels, but invalidate the cache when the business outcome weights in [BUSINESS_OUTCOME_WEIGHTS] change.

Human review integration: The recommended_action field should directly feed your review queue router. Claims scored verify_immediately bypass human review if their confidence is also above your auto-verification threshold. Claims scored queue_for_review enter the human queue sorted by priority_score descending. Claims scored defer are held in a low-priority backlog and re-evaluated when evidence updates arrive. Claims scored auto_dismiss are archived with the justification logged for audit. Never auto-dismiss claims with CLAIM_IMPACT above a configured safety threshold without human confirmation, regardless of the model's recommendation.

Logging and observability: Log every scoring call with the input claim ID, the model's raw output, the validated score, the retry count, and the final routing decision. Attach the priority_score as a metric on your verification traces so you can monitor score drift over time. Set up an alert if the mean priority score shifts by more than 0.2 within a rolling window, as this may indicate a change in upstream evidence quality, claim extraction behavior, or model behavior after a provider update. Periodically sample scored claims and have a human reviewer assess whether the priority ordering matches operational intuition—use this to calibrate the [BUSINESS_OUTCOME_WEIGHTS] parameters.

What to avoid: Do not use this prompt to make final verification decisions. The priority score is a resource allocation signal, not a truth judgment. Do not feed unvalidated priority scores directly into customer-facing dashboards or compliance reports without human review of the scoring rationale. Do not skip the output validation step—model-generated priority scores can drift, hallucinate justifications, or produce out-of-range values under load. Finally, do not treat the [BUSINESS_OUTCOME_WEIGHTS] as static; review them quarterly against actual verification outcomes and business impact data to prevent priority miscalibration over time.