Triage Priority Scoring Prompt Template

This prompt is for triage engineers and operations teams who need to score and rank AI-generated work items before they enter a human review queue. The job-to-be-done is consistent, explainable prioritization: turning a stream of review items into an ordered list where the most critical work surfaces first. Use it when your review queue receives more items than reviewers can immediately handle and you need the AI to pre-score each item so humans can work from the top of the queue with confidence. The ideal user is someone who can define what 'urgent,' 'high-impact,' and 'high-risk' mean in their operational context and can provide those definitions as part of the prompt's input variables.

Do not use this prompt when the review queue is small enough for a human to triage everything in a single pass, or when the cost of a mis-prioritized item is catastrophic and no automated scoring should influence queue order. It is also inappropriate when priority depends on real-time external signals—such as a live incident dashboard or a customer's current emotional state—that the model cannot access. This prompt is a static scoring tool, not a dynamic monitoring system. If your triage workflow requires SLA timers, breach predictions, or multi-stakeholder routing, pair this prompt with the sibling playbooks for SLA breach prediction or stakeholder identification rather than overloading the priority score with those concerns.

Before using this prompt, you must define the scoring dimensions (urgency, impact, risk), the scale for each dimension, and the rules for combining them into a final priority score. You must also prepare a calibration set: at least 20–30 items that humans have already prioritized, so you can test whether the prompt's scores align with human judgment. Without calibration data, you cannot detect systematic scoring errors such as consistently underweighting risk or overweighting urgency. Start by running the prompt against your calibration set, compare scores to human-assigned priorities, and adjust the dimension definitions or combination rules until the prompt's output is reliable enough to trust in production.

This prompt template is the core instruction set for a triage priority scoring system. It is designed to be dropped into an AI harness where the placeholders are populated by application logic before the model call. The prompt forces the model to produce a structured, calibrated priority score by evaluating three independent dimensions—urgency, impact, and risk—and then synthesizing them into a final score with explicit reasoning. This decomposition prevents the model from defaulting to a gut-feeling 'high' or 'low' and instead builds a defensible, auditable trail for why an item landed in a specific queue position.

codeCopy
You are a triage priority scoring agent. Your task is to evaluate a work item and produce a structured priority score.

## INPUT
[INPUT]

## CONTEXT
[CONTEXT]

## CONSTRAINTS
- Do not guess missing information. If a factor cannot be determined, mark it as 'UNKNOWN' and explain how it affects the score.
- Apply the [RISK_LEVEL] tolerance when evaluating impact and risk. A low risk tolerance should increase the score for ambiguous threats.
- If the item matches any pattern in [ESCALATION_RULES], bypass scoring and return an immediate escalation flag.

## SCORING INSTRUCTIONS
Evaluate the item across three independent dimensions on a scale of 1 (lowest) to 5 (highest):

1.  **Urgency**: Time-sensitivity. Does the item have a hard deadline, an SLA, or a rapidly decaying value? Consider [SLA_WINDOW] if provided.
2.  **Impact**: The blast radius if the item is not resolved or the action is taken incorrectly. Consider the number of users, systems, or revenue affected.
3.  **Risk**: The probability and severity of a negative outcome, including safety, compliance, or data integrity risks.

Calculate the **Final Priority Score** as a weighted average: `(Urgency * 0.4) + (Impact * 0.4) + (Risk * 0.2)`. Round to one decimal place.

## OUTPUT_SCHEMA
You must respond with a single valid JSON object conforming to this schema:
{
  "item_id": "string",
  "final_score": "number",
  "score_components": {
    "urgency": {
      "score": "number (1-5)",
      "rationale": "string"
    },
    "impact": {
      "score": "number (1-5)",
      "rationale": "string"
    },
    "risk": {
      "score": "number (1-5)",
      "rationale": "string"
    }
  },
  "missing_information": ["string"],
  "escalation_flag": "boolean",
  "escalation_reason": "string | null"
}

## EXAMPLES
[EXAMPLES]

To adapt this template, start by defining your [INPUT] and [CONTEXT] variables. [INPUT] should be the raw text of the work item, while [CONTEXT] can be a pre-assembled string of relevant customer history, system state, or policy documents retrieved via RAG. The [RISK_LEVEL] placeholder is a critical tuning knob; set it to a string like 'LOW', 'MEDIUM', or 'HIGH' based on the operational domain. For a healthcare or finance application, a 'LOW' risk tolerance would instruct the model to score ambiguous threats more aggressively. The [ESCALATION_RULES] placeholder should be a concise list of non-negotiable patterns, such as 'mention of data breach' or 'PII exposure', that force an immediate escalation_flag: true and bypass the scoring logic entirely. Finally, populate [EXAMPLES] with a few-shot set of scored items that demonstrate the desired calibration, especially for edge cases where urgency and risk conflict.

This prompt is designed to be called as a deterministic scoring step within a larger triage pipeline, not as a standalone chat interaction. The primary integration point is immediately after a new work item is ingested and before it is routed to a human queue. The application should construct the [INPUT] by serializing the item's title, description, and any available metadata (e.g., affected system, customer tier, SLA deadline) into a structured text block. The [CONTEXT] placeholder must be populated with your organization's specific priority definitions, including what constitutes a P1/P2/P3/P4 incident, your business hours, and any explicit risk-weighting policies. Do not rely on the model's general knowledge of priority; inject your runbook definitions directly into the context to ensure calibration against your operational reality.

The model's response must be validated against a strict JSON schema before the score is trusted. The application layer should parse the output and confirm the presence of integer fields for urgency_score, impact_score, risk_score, and the final composite_priority_score. A retry loop with a maximum of two attempts is recommended: if the initial output fails schema validation, the retry prompt should include the raw response and the specific validation error (e.g., 'missing required field: risk_score'). For high-risk environments, implement a circuit breaker that routes the item to a 'Review Required' queue with a null score if validation fails after retries, ensuring no item is dropped. Log the raw prompt, the model's response, the validated score, and the chosen model version to your observability platform for later calibration analysis.

Model choice involves a trade-off between latency and reasoning depth. For high-volume, low-latency queues, a fast model like GPT-4o-mini or Claude Haiku is often sufficient if the priority definitions are unambiguous. For complex items where impact and risk are deeply intertwined, a stronger reasoning model like GPT-4o or Claude Sonnet may produce more calibrated scores, especially for the risk_factor_decomposition field. To prevent score drift, run a weekly eval job that samples 100 scored items and compares the model-assigned composite_priority_score against a human-assigned priority label. Monitor the distribution of scores; a sudden spike in P1 assignments often indicates a prompt regression or a change in the upstream data source, not a real-world crisis. The next step after scoring is to pass the validated JSON payload to your queue router, using the composite_priority_score to determine the target queue and SLA timer.