Review Item Actionability Scoring Prompt for Triage Decisions

The Review Item Actionability Scoring Prompt acts as a pre-queue gate that evaluates whether a work item contains sufficient information for a human reviewer to make a confident decision. Triage engineers and operations leads should deploy this prompt before items enter any human review queue—whether for compliance checks, incident response, content moderation, or approval workflows. The prompt produces three outputs: an actionability score indicating overall readiness, a list of specific blockers that prevent resolution, and a resolution readiness assessment that categorizes the item as ready, needs-enrichment, or requires-redirect. Use this prompt when your review queues are accumulating items that reviewers bounce back for missing context, when you need to enforce evidence standards before consuming reviewer time, or when you want to measure queue health by tracking the ratio of actionable to non-actionable items over time.

The prompt requires structured input containing the review item's content, its source or origin system, the decision type the reviewer must make, and any available metadata such as priority signals or SLA context. The model evaluates completeness across multiple dimensions: whether required evidence is present and cited, whether the item's scope is bounded enough for a decision, whether contradictory information exists that would block resolution, and whether the decision authority is clear. The output schema includes an actionability_score on a 0-100 scale with defined thresholds, a blockers array where each blocker specifies the missing element and a suggested remediation, and a resolution_readiness enum of ready, needs_enrichment, or requires_redirect. Implement this prompt with validation that rejects scores above 80 when blockers are present—a common failure mode where the model acknowledges gaps but still scores items as actionable. Wire the output into your queue routing logic so that needs_enrichment items return to the submitter with specific blocker descriptions, while requires_redirect items route to a different queue or team entirely.

Do not use this prompt when the item has already been reviewed and requires only a decision record, when the decision is fully automatable without human judgment, or when the review workflow requires specialized domain judgment that the model cannot assess—such as legal interpretation of novel case law or clinical diagnosis from raw imaging. The prompt is also inappropriate for real-time safety-critical systems where the latency of an LLM scoring step would violate response time requirements. Before deploying, run calibration tests comparing the prompt's actionability scores against human reviewer assessments on a sample of 50-100 items, paying particular attention to items the prompt scores as actionable that reviewers later return as incomplete. Log every scoring decision with the item identifier, score, blockers found, and the model version used, so that triage accuracy can be audited and regressions detected when prompt or model versions change.

This prompt template is designed to be pasted directly into your system instructions or sent as a user message. It instructs the model to act as a triage engineer, evaluating a work item against strict actionability criteria. The goal is not to resolve the item, but to produce a structured score that tells a queue manager whether a human reviewer has everything they need to make a decision immediately. Replace every square-bracket placeholder with your specific data, schemas, and policies before use.

textCopy
You are a triage scoring engine for a human review queue. Your only job is to evaluate whether a given review item is actionable by a human reviewer. Do not resolve the item. Do not make the decision. Only assess its readiness for human decision-making.

## Input
You will receive a review item containing:
- [ITEM_DESCRIPTION]
- [EVIDENCE_ATTACHMENTS]
- [REQUIRED_DECISION_TYPE]
- [REVIEWER_ROLE]

## Scoring Criteria
Evaluate the item on the following dimensions, each on a scale of 1 (blocked) to 5 (fully ready):

1. **Information Completeness**: Does the item contain all facts, context, and evidence a reviewer needs to decide? Deduct for missing timestamps, IDs, source documents, or referenced data not included.
2. **Decision Clarity**: Is the required decision explicitly stated and unambiguous? Deduct for vague asks like "review this" without a specific question or approval target.
3. **Evidence Grounding**: Is every claim in the item directly supported by an attached or cited piece of evidence? Deduct for unsupported assertions or missing source links.
4. **Context Sufficiency**: Can a reviewer with the stated role understand the item without external research? Deduct for domain jargon without explanation, missing background, or assumed knowledge.
5. **Resolution Path**: Is the next step after review obvious? Deduct if the item doesn't specify what happens after approval, rejection, or escalation.

## Blockers
Identify any blocking conditions that make the item completely unactionable. A blocker is a missing piece of information without which no reviewer could responsibly decide. Examples:
- Missing required field: [LIST_REQUIRED_FIELDS]
- Referenced evidence not attached
- Decision type incompatible with reviewer role
- Contradictory instructions

## Output Schema
Return a single JSON object with this exact structure:
{
  "actionability_score": number (1-5, weighted average of the five criteria),
  "score_breakdown": {
    "information_completeness": number,
    "decision_clarity": number,
    "evidence_grounding": number,
    "context_sufficiency": number,
    "resolution_path": number
  },
  "is_actionable": boolean (true if actionability_score >= [ACTIONABILITY_THRESHOLD] and no blockers exist),
  "blockers": [
    {
      "blocker_type": string,
      "description": string,
      "missing_information": string
    }
  ],
  "resolution_readiness": "ready" | "needs_enrichment" | "blocked",
  "reviewer_guidance": string (if not actionable, what specific information must be added before this can be reviewed)
}

## Constraints
- Do not fabricate missing evidence or assume facts not present in the input.
- If the item is blocked, the reviewer_guidance field must specify exactly what is missing.
- Score conservatively. When in doubt, flag a blocker rather than assume readiness.
- Never output anything outside the JSON object.

After pasting this template, you must adapt the placeholders to match your operational reality. The [LIST_REQUIRED_FIELDS] placeholder should be replaced with the actual schema fields your review items must contain—such as ticket_id, customer_id, timestamp, or affected_system. The [ACTIONABILITY_THRESHOLD] should be set based on your team's tolerance for incomplete items; a typical starting point is 3.5, but teams handling high-risk decisions often raise this to 4.0. The [REQUIRED_DECISION_TYPE] and [REVIEWER_ROLE] placeholders should be populated dynamically by your application before the prompt is sent, not left as static text. If your review items have additional mandatory fields, add them to the Input section and reference them in the Blockers criteria.

Before deploying this prompt into a production triage pipeline, run it against a golden dataset of 50–100 previously reviewed items where you know the ground-truth actionability status. Measure whether the model's is_actionable flag matches human judgment. Pay special attention to false negatives—items the model scores as blocked that humans successfully resolved—because these will unnecessarily inflate your review queue. If you observe systematic underscoring on a particular dimension, adjust the threshold or refine the criteria descriptions. For high-stakes domains such as compliance or safety reviews, always route items scored near the threshold to a human triage lead for a second opinion rather than auto-accepting the model's score.

The actionability scoring prompt is designed to sit between item ingestion and queue assignment in a triage pipeline. It should be called after a review item is fully packaged with its evidence and context, but before it is routed to a specific reviewer or team. The prompt's output—a structured score with blockers and resolution readiness—determines whether the item proceeds to a human queue, gets bounced back for more information, or is auto-resolved if confidence is high enough. This is not a fire-and-forget prompt; the harness must validate the output schema, enforce scoring thresholds, and log decisions for auditability.

Integration steps: 1) Assemble the prompt with the [REVIEW_ITEM] containing the full packaged context, evidence, and any prior triage notes. 2) Call the model with response_format set to the defined JSON schema, enforcing actionability_score (0-100), blockers (array of strings), and resolution_readiness (enum: ready, blocked, needs_clarification). 3) Validate the response: if the schema is malformed, retry once with a repair prompt that includes the validation error. If the score is above a configured auto-resolution threshold (e.g., 85) and resolution_readiness is ready, route to a low-priority or auto-resolution queue. If blockers is non-empty or resolution_readiness is blocked, route to a clarification request workflow that asks the originating system or user for the missing information. 4) Log the full prompt, response, and routing decision to an audit table with a timestamp and model version. This log is critical for calibrating thresholds and debugging misrouted items.

Model choice and performance: Use a model with strong structured output support and reasoning capabilities, such as GPT-4o or Claude 3.5 Sonnet. Avoid smaller or faster models for this task because the cost of misclassifying a blocked item as actionable is high—it wastes reviewer time and delays resolution. If latency is a concern, consider a two-stage approach: a fast classifier to filter obviously actionable items (score > 90, no blockers), and this full prompt for the ambiguous middle. Retry logic: If the model returns a score but the blockers array contains items that contradict a high score (e.g., score > 70 but blockers include "missing critical evidence"), flag the item for human review of the scoring itself—this is a model reasoning failure, not a schema failure.

Human review integration: The output of this prompt feeds directly into a triage dashboard. Display the actionability_score as a prominent badge, list blockers as a checklist the reviewer can verify or dismiss, and use resolution_readiness to color-code the queue. If a reviewer overrides the score, capture the override reason and feed it back as a few-shot example for future prompt iterations. What to avoid: Do not use this prompt to make the final resolution decision—it scores actionability, not correctness. Do not skip validation; an unvalidated JSON output will break downstream routing logic. Do not set the auto-resolution threshold without monitoring false-positive rates for at least two weeks in production.