Verification Queue Priority Scoring Prompt

This prompt is designed for review queue managers and verification pipeline operators who need to assign a numeric priority score to incoming verification tasks. It ingests structured data about a claim, its context, and its constraints, then outputs a calibrated priority score along with the factor breakdown that produced it. Use this prompt when your verification system must order work by business impact, not just arrival time. The prompt assumes you have already extracted claims and gathered basic metadata such as SLA deadlines, potential harm categories, and evidence availability flags. It does not perform claim extraction or evidence retrieval itself. It belongs in the triage layer, after claim intake and before reviewer assignment.

The ideal user is an engineering lead or operations manager integrating this prompt into an automated verification pipeline. The required context includes a structured input object with fields for claim text, claim type, potential harm severity, SLA deadline timestamp, evidence availability count, and any domain-specific urgency tags. Without this structured input, the prompt cannot produce a reliable priority score. Do not use this prompt for real-time content moderation decisions where latency is measured in milliseconds—it is designed for batch or near-real-time queue management where scoring can take a few seconds. Also avoid using it as a standalone decision-maker for high-stakes individual claims; the output should feed into a broader routing system that may include human override.

Before deploying, ensure your intake pipeline consistently populates all required fields. Missing SLA deadlines or harm classifications will produce unreliable scores. Wire the output into your queue management system so that higher scores translate to earlier reviewer assignment. Start by running the prompt against a historical sample of claims with known resolution outcomes to calibrate whether the scoring correlates with actual business impact. If correlation is weak, adjust the factor weights or add domain-specific factors before scaling to production. Never treat the score as an absolute truth—it is a prioritization signal that should be combined with operational constraints like reviewer availability and skill matching.

This prompt template is the core instruction set for a Verification Queue Priority Scoring system. It is designed to be copied directly into your application code, test suite, or orchestration layer. Before sending this prompt to a model, every square-bracket placeholder must be replaced with a pre-validated value from your upstream system. Do not pass raw, unsanitized user input into these placeholders; the priority score is only as reliable as the structured data you provide.

textCopy
You are a priority scoring agent for a verification operations queue. Your task is to analyze an incoming verification task and assign a single numeric priority score from 1 (lowest) to 100 (highest) based on the provided context.

# INPUT DATA
- **Claim Text:** [CLAIM_TEXT]
- **Claim Domain:** [CLAIM_DOMAIN]
- **Reported By:** [REPORTER_ROLE]
- **Potential Harm Description:** [POTENTIAL_HARM]
- **SLA Deadline (ISO 8601):** [SLA_DEADLINE]
- **Current Time (ISO 8601):** [CURRENT_TIME]
- **Available Evidence Count:** [EVIDENCE_COUNT]
- **Evidence Source Types:** [EVIDENCE_SOURCE_TYPES]
- **Auto-Verification Confidence (0.0-1.0):** [AUTO_VERIFICATION_CONFIDENCE]

# SCORING RUBRIC
Calculate the final score by evaluating each factor below and summing its contribution. The maximum possible score is 100.

1.  **Urgency (0-40 points):** Calculate the time remaining until the [SLA_DEADLINE]. If the deadline has passed, assign 40 points. If the time remaining is less than 1 hour, assign 35 points. Scale down linearly to 0 points if more than 72 hours remain.
2.  **Potential Harm (0-35 points):** Assess [POTENTIAL_HARM].
    *   **Critical Harm (e.g., public safety, financial system risk, imminent real-world danger):** 35 points.
    *   **Significant Harm (e.g., major reputational risk, large-scale misinformation, regulatory penalty):** 25 points.
    *   **Moderate Harm (e.g., individual user impact, misleading technical documentation):** 15 points.
    *   **Low Harm (e.g., trivial factual error, stylistic inaccuracy):** 5 points.
    *   **No Harm:** 0 points.
3.  **Verification Difficulty (0-25 points):** Assess the difficulty of verification based on available evidence.
    *   If [EVIDENCE_COUNT] is 0, assign 25 points.
    *   If [EVIDENCE_COUNT] is 1-2 and [AUTO_VERIFICATION_CONFIDENCE] is less than 0.5, assign 20 points.
    *   If [EVIDENCE_COUNT] is 1-2 and [AUTO_VERIFICATION_CONFIDENCE] is 0.5 or greater, assign 10 points.
    *   If [EVIDENCE_COUNT] is 3 or more and [AUTO_VERIFICATION_CONFIDENCE] is less than 0.7, assign 10 points.
    *   If [EVIDENCE_COUNT] is 3 or more and [AUTO_VERIFICATION_CONFIDENCE] is 0.7 or greater, assign 0 points.

# CONSTRAINTS
- You must output a single, valid JSON object. No other text.
- The JSON object must conform to the provided output schema.
- Do not invent new factors or ignore the rubric.
- If any input field is missing or invalid, set the score to -1 and provide a concise error reason.

# OUTPUT SCHEMA
{
  "priority_score": <integer 1-100 or -1 for error>,
  "score_breakdown": {
    "urgency_score": <integer 0-40>,
    "harm_score": <integer 0-35>,
    "difficulty_score": <integer 0-25>
  },
  "rationale": "<A concise, one-sentence summary of the primary driver for the score.>"
}

To adapt this template, first map your internal data model to the INPUT DATA fields. The POTENTIAL_HARM field is the most subjective; you may need a separate classification prompt to populate it reliably before calling this scoring prompt. The rubric's point thresholds are a starting point and must be calibrated against your operational data. After deploying, monitor the correlation between the priority_score and actual business impact, and adjust the point allocations in the rubric accordingly. A common failure mode is a high volume of tasks scoring near 100, which indicates the rubric is not creating enough differentiation to be useful for queue management.

The priority scoring prompt is not a standalone tool; it is a decision-making component inside a larger verification triage system. To integrate it, build a harness that calls the prompt after claim extraction and evidence retrieval but before task assignment. The harness must supply the required inputs: the claim text, extracted metadata (source, timestamp, author), any available evidence snippets, the SLA deadline, and a risk profile if one exists. The prompt returns a structured JSON object with a numeric priority score, a breakdown of contributing factors, and a confidence estimate. Do not treat this score as the final word—it is a recommendation that your application must validate, log, and potentially override.

Validation is the first line of defense. Before accepting the model's output, check that the priority score falls within the expected numeric range (e.g., 0-100), that all required factor fields are present and non-null, and that the confidence score is a valid float between 0 and 1. If validation fails, implement a retry loop with a maximum of two additional attempts, appending the specific validation error to the retry prompt. Log every validation failure and retry attempt for observability. For high-risk domains, add a circuit breaker: if the model cannot produce a valid score after three attempts, escalate the task directly to a human reviewer with a flag indicating an automated scoring failure. Never silently default to a mid-range priority score, as this can bury urgent claims.

Model choice matters for this workflow. Use a model with strong instruction-following and structured output capabilities, such as GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Avoid smaller, faster models for initial scoring unless you have calibrated their performance against your specific priority rubric. If latency is a concern, consider a two-tier approach: use a fast model for initial scoring of low-risk claims and a more capable model for claims flagged with high potential harm or tight SLA deadlines. Store the model version and prompt template hash alongside every score to enable downstream analysis of scoring drift when models or prompts change.

Human review integration is essential. The priority score should feed directly into a review queue management system, but the system must allow human operators to override scores. Capture every override as a structured feedback record containing the original score, the reviewer's adjusted score, and a brief reason. Use these records to evaluate the prompt's performance over time. Measure the correlation between predicted priority scores and actual business impact (e.g., whether high-priority claims indeed resulted in corrections, retractions, or harm prevention). If correlation drops below a defined threshold, trigger a prompt review cycle. Additionally, implement a sampling strategy where a percentage of auto-scored tasks—especially those near SLA boundaries—are reviewed by a second human to catch systematic scoring errors before they affect queue outcomes.

Finally, wire the prompt into your observability stack. Log the full prompt input, the raw model response, the validated output, and any overrides. Include trace IDs that link the priority score to the original claim, the evidence retrieval step, and the eventual verification outcome. This traceability is critical for auditing, debugging scoring anomalies, and demonstrating to stakeholders that the automated prioritization is fair, explainable, and continuously improving. Avoid deploying this prompt without a feedback loop; a priority scoring system that never learns from its mistakes will drift and eventually undermine trust in the entire verification pipeline.