SLA Breach Risk Prediction Prompt

This prompt is for operations engineers and SRE teams who need an automated, auditable signal to predict which queued items will breach their SLA targets given current throughput rates. The job-to-be-done is proactive resource reallocation: instead of discovering a breach after it happens, the system forecasts time-to-breach so the team can escalate or shift capacity before the deadline expires. The ideal user is an engineer building or maintaining a queue-based processing system—support ticket pipelines, async job workers, incident response queues, or order processing backlogs—where each item carries an SLA deadline and the cost of missing it is measurable in dollars, compliance exposure, or customer trust.

The prompt requires structured input: a snapshot of the current queue state including item IDs, arrival times, SLA deadlines, and processing stage, plus metadata about current throughput (items completed per minute/hour), available workers, and any known bottlenecks. It is designed to be called on a schedule (every N minutes) or triggered by queue-depth thresholds crossing a configured limit. The output is a breach risk score per item, a time-remaining estimate, and a recommended escalation trigger—not a generic alert, but a specific signal that says 'Item X has a 92% probability of breaching in 14 minutes unless throughput increases by 3 items/minute.' This precision lets on-call engineers make fast, defensible decisions about pulling in additional resources or preemptively communicating with stakeholders.

Do not use this prompt when the queue lacks structured SLA metadata, when throughput is too volatile for meaningful prediction (e.g., worker pools that scale unpredictably), or when the cost of a false-positive escalation is higher than the cost of a missed SLA. It is also inappropriate for queues where items have interdependent completion order constraints that the prompt cannot model—this is a throughput-based predictor, not a constraint solver. For high-stakes environments where a breach triggers regulatory reporting or contractual penalties, always pair this prompt with a human review step before the escalation trigger fires. The prompt provides the signal; your harness should enforce the approval gate.

This prompt template is designed to be dropped into an application that has already gathered the necessary queue state and SLA metadata. It instructs the model to act as a deterministic risk calculator, not a conversational assistant. The output is a strict JSON object suitable for direct consumption by a monitoring dashboard, an alerting system, or a workflow engine. The template uses square-bracket placeholders for all dynamic inputs, making it easy to parameterize in code before each inference call.

codeCopy
You are an SLA breach risk calculator. Your only job is to analyze the provided queue state and SLA metadata to predict breach risk. Do not engage in conversation. Return a single, valid JSON object with no additional text, markdown fences, or commentary.

## INPUT
- **Queue State:** [QUEUE_STATE_JSON]
- **SLA Metadata:** [SLA_METADATA_JSON]

## TASK
1. Calculate the estimated time to process all items currently ahead of the target item in the queue, based on the historical average processing rate.
2. Compare this estimated processing time against the target item's SLA deadline.
3. Produce a breach risk score from 0.0 (no risk) to 1.0 (certain breach).
4. Estimate the time remaining until the SLA deadline is breached. Use a negative value if the deadline has already passed.
5. Recommend an escalation trigger based on the risk score and the [RISK_THRESHOLD] provided.

## CONSTRAINTS
- If the queue state is empty or the target item is already being processed, the risk score must be 0.0.
- If the historical average processing rate is zero or unavailable, set the risk score to 0.5 and flag the estimate as low confidence.
- The escalation trigger must be one of: 'none', 'warn', 'escalate', 'critical'.
- Base all calculations only on the provided data. Do not invent or assume missing values.

## OUTPUT SCHEMA
{
  "risk_score": <float 0.0-1.0>,
  "time_remaining_seconds": <integer, negative if breached>,
  "escalation_trigger": "<none|warn|escalate|critical>",
  "confidence": "<high|medium|low>",
  "calculation_notes": "<brief explanation of the calculation>"
}

To adapt this template for your own system, replace the placeholders with live data. [QUEUE_STATE_JSON] should be a serialized JSON object containing the target item's position, the total items ahead of it, and the historical average processing rate. [SLA_METADATA_JSON] should include the SLA deadline timestamp and the target item's arrival time. The [RISK_THRESHOLD] is a numeric value you set in your application logic (e.g., 0.7) that determines the boundary between 'warn' and 'escalate'. For high-stakes production systems, always validate the output JSON against the schema before acting on the escalation trigger, and log the full input and output for auditability.

This prompt is not a dashboard widget; it is a decision trigger. Integrate it into a scheduled job or event-driven workflow that runs whenever queue depth changes, a new item is enqueued, or a periodic SLA audit fires. The prompt expects a snapshot of the current queue state, throughput metrics, and the target item's SLA deadline. The output is a structured breach risk score that your application must parse and act on—typically by triggering an escalation, reassigning resources, or paging an on-call engineer. Do not use this prompt for real-time per-event scoring on every ticket creation if your queue is high-throughput; batch the evaluation or sample items approaching the danger zone to control cost and latency.

The application harness should enforce a strict contract around the prompt's inputs and outputs. Before calling the model, assemble the [QUEUE_SNAPSHOT] with the item's current position, the [THROUGHPUT_METRICS] as a rolling average of completions per minute, and the [SLA_DEADLINE] in a parseable ISO-8601 timestamp. After receiving the response, validate the JSON output against a schema that requires breach_risk_score (0-100), estimated_time_remaining_minutes (integer), and recommended_escalation_trigger (boolean). If validation fails, retry once with a stricter prompt variant that emphasizes schema adherence. Log every prediction alongside the actual outcome—did the item breach?—to build a calibration dataset. This feedback loop is essential for tuning the [RISK_THRESHOLD] parameter that controls when your system escalates. A common failure mode is a false-positive breach alert caused by a temporary throughput dip that self-corrects; mitigate this by requiring two consecutive high-risk predictions before triggering a page.

Model choice matters here more than in many classification prompts. The prompt requires numerical reasoning over time-series-like data (queue position, throughput rates, deadlines). Prefer a model with strong quantitative reasoning benchmarks. If using a smaller or faster model for cost reasons, add a validation layer that recalculates the estimated_time_remaining_minutes using a simple deterministic formula (position / throughput_rate) and flags the prediction for human review if the model's estimate deviates by more than 20%. For high-stakes SLAs with financial penalties, always route predictions above a [REVIEW_THRESHOLD] to a human operations lead before escalation actions fire. Never allow the model's output to directly trigger a customer-facing SLA breach notification without this review step. The harness should also implement a dead-man's switch: if the prediction service is unreachable, default to the most conservative escalation behavior rather than silently failing.