Review Item SLA Breach Prediction Prompt for Proactive Escalation

This prompt is designed for operations leads and platform engineers who manage SLA-bound human review queues. Use it when an AI system needs to evaluate pending review items against their service level agreements and predict which items are at risk of breaching before the deadline. The prompt produces a structured breach risk assessment with time-remaining estimates, confidence levels, and recommended pre-escalation actions. It belongs in workflows where review items have defined SLAs, timestamps are available, and proactive escalation can prevent missed deadlines.

The ideal deployment context includes a review queue with clear SLA definitions per item type, reliable creation and deadline timestamps, and an escalation path that can accept structured alerts. The prompt expects inputs such as the current time, item creation time, SLA duration, and any known processing delays. It works best when integrated into a scheduled job that scans the queue at regular intervals—for example, every 15 minutes—and pushes breach predictions to an on-call channel or escalation dashboard. The output includes a risk level, estimated time remaining, confidence in the prediction, and a recommended action such as reassigning the item, notifying the reviewer, or triggering a manager alert.

Do not use this prompt for queues without SLA definitions, for real-time sub-second decisions, or when the cost of a false alarm outweighs the cost of a missed breach. It is also unsuitable for queues where timestamps are unreliable or where review items can be paused without updating their deadline. If your escalation workflow cannot absorb occasional false positives, pair this prompt with a confidence threshold filter and human-in-the-loop validation before alerts are sent. For high-stakes environments, implement a shadow mode first to measure false-alarm rate and missed breach predictions against historical data before enabling live escalation.

This prompt template is designed to be wired directly into your review queue processing pipeline. It instructs the model to act as an SLA compliance analyst, evaluating a single review item against your defined service-level agreements. The model will produce a structured breach risk prediction, a time-remaining estimate, and a set of recommended pre-escalation actions. The primary goal is to move from a reactive 'SLA has been breached' alert to a proactive 'SLA is likely to be breached' workflow, giving human operators time to intervene.

textCopy
You are an SLA compliance analyst for a review operations team. Your task is to predict the risk of an SLA breach for a single review item and recommend pre-escalation actions.

# INPUT DATA
Review Item: [REVIEW_ITEM_DETAILS]
Current Queue State: [QUEUE_CONTEXT]

# SLA RULES
[SLA_RULES]

# OUTPUT SCHEMA
You must respond with a single JSON object conforming to this schema:
{
  "item_id": "string",
  "breach_risk": "low | medium | high | critical",
  "time_remaining_estimate": "string (e.g., '45 minutes', '2 hours')",
  "breach_prediction_confidence": 0.0-1.0,
  "risk_factors": ["string"],
  "recommended_pre_escalation_actions": [
    {
      "action": "string (clear, specific action)",
      "owner_hint": "string (suggested role or team)",
      "rationale": "string (why this action is recommended now)"
    }
  ],
  "abstention_flag": false,
  "abstention_reason": null
}

# CONSTRAINTS
- If the [REVIEW_ITEM_DETAILS] are insufficient to make a prediction, set `abstention_flag` to true and explain why in `abstention_reason`. Do not guess.
- Base your prediction strictly on the provided [SLA_RULES] and [QUEUE_CONTEXT].
- `time_remaining_estimate` must be a human-readable string, not a raw timestamp.
- `breach_prediction_confidence` must reflect your certainty in the prediction, not the severity of the risk.
- Pre-escalation actions must be actionable and specific. Do not suggest 'monitor the queue'.

To adapt this template, replace the square-bracket placeholders with live data from your system. [REVIEW_ITEM_DETAILS] should be a structured text block containing the item's creation time, current status, assigned team, and any other relevant metadata. [QUEUE_CONTEXT] should describe the current state of the queue, such as the number of items ahead of this one and the average handling time. [SLA_RULES] must be a clear, text-based representation of your service-level agreements (e.g., 'Critical priority items must receive a first response within 15 minutes'). For high-stakes environments, always route outputs where breach_risk is 'high' or 'critical' directly to a human dispatcher and log the model's breach_prediction_confidence alongside the final outcome to track calibration over time.

The SLA breach prediction prompt is designed to be called by a scheduled job or an event-driven trigger—such as a new item entering the review queue or a periodic sweep of pending items—rather than by an end user. The application layer is responsible for gathering the required inputs: the review item's current state, its SLA deadline, queue depth, historical resolution times for similar items, and any blocking conditions. These inputs must be assembled into a structured context object before the prompt is rendered. Because the output directly influences whether a human is interrupted with an escalation, the harness must treat every prediction as a candidate for review, not as an autonomous decision to page someone.

The API call should use a model with strong reasoning capabilities and support for structured output. Request a JSON response conforming to a strict schema that includes breach_risk_score (0-100), estimated_minutes_remaining, confidence_level (HIGH/MEDIUM/LOW), contributing_factors (array of strings), and recommended_pre_escalation_actions (array of objects with action and owner fields). Set temperature to 0 or a very low value to maximize consistency. Implement a retry wrapper with up to 3 attempts, using exponential backoff, and validate each response against the schema before accepting it. If the model returns malformed JSON, missing required fields, or values outside expected ranges, discard the response and retry. After 3 consecutive failures, log the failure and create a manual review item flagged as 'prediction_failure' so the queue is not left unmonitored.

The most critical integration point is the escalation gate. Do not automatically notify on-call staff or page responders based solely on the model's output. Instead, write the prediction result alongside the review item in your queue database. A separate application rule evaluates whether to escalate: for example, escalate if breach_risk_score > 80 AND confidence_level != 'LOW' AND the item is not already assigned to a reviewer. When escalation is triggered, the system should generate a pre-escalation summary using the recommended_pre_escalation_actions and attach the full prediction payload for context. This keeps the human in the loop for high-stakes decisions while allowing low-risk predictions to simply update a dashboard.

Logging and observability are essential for tuning the system over time. For every prediction, log the input context hash, the model version, the raw and parsed outputs, the validation result, and whether the prediction triggered an escalation. Separately, record the ground truth outcome: whether the item actually breached its SLA and the actual resolution time. This data feeds into offline evaluation to measure the false-alarm rate (items predicted to breach that didn't) and the missed-breach rate (items that breached without a high-risk prediction). Use these metrics to adjust the escalation threshold and to decide when the prompt itself needs revision. If the false-alarm rate exceeds 20% or the missed-breach rate exceeds 5%, trigger a prompt review cycle.

Model choice matters for cost and latency. This prompt is not latency-sensitive in the way a real-time chat response is—a 5-10 second inference time is acceptable for a background prediction job. However, if you are scanning thousands of queue items, batch the predictions and consider using a cheaper model for the initial sweep, reserving a more capable model for items that score above a lower threshold (e.g., breach_risk_score > 40). This tiered approach reduces cost while preserving accuracy on borderline cases. Always run the full evaluation suite against any model change before deploying to production.

Finally, treat this prompt as part of a larger review queue health system. The SLA breach prediction should feed into backlog summarization dashboards, capacity planning estimates, and post-mortem analysis. Avoid the temptation to make the prompt do everything—it should predict breach risk, not also summarize the backlog, assign reviewers, or generate customer communications. Each of those functions deserves its own tested prompt with its own harness, validation, and evaluation criteria.