Verification SLA Classification Prompt

This prompt is designed for the critical handoff point where a new verification task arrives and must be classified before any actual verification work begins. The primary job-to-be-done is to analyze an incoming claim, assess its risk profile, urgency, and complexity, and then produce a structured SLA assignment that dictates the deadline, required review depth, and escalation triggers. The ideal user is a platform engineer or operations lead embedding this classification step into an automated verification pipeline. Required context includes the claim text, its source, any available metadata about the claim's origin, and your organization's SLA tier definitions. Without this context, the model cannot make a calibrated risk assessment and will default to generic, potentially unsafe classifications.

Do not use this prompt for the actual verification of claims—it only handles classification and routing metadata that precedes verification work. It is also not a replacement for a full risk assessment framework; it operationalizes existing SLA policies into consistent decisions. The prompt is most valuable when your pipeline processes heterogeneous claims at volume and you need to prevent high-risk claims from sitting in low-priority queues. For example, a claim about a publicly traded company's earnings made during market hours should receive a higher SLA tier than a claim about a minor product description typo. The prompt enforces this distinction programmatically, producing auditable records that explain why each task received its assigned tier. Before implementing, ensure your SLA tier definitions are documented with clear criteria for deadline windows, review depth requirements, and escalation conditions. Ambiguous tier definitions will produce inconsistent classifications regardless of prompt quality.

After implementing this classification step, the next action is to wire the output into your queue management system so that SLA deadlines are enforced and escalation triggers are monitored. Avoid the common mistake of treating the SLA classification as static—claims may be reclassified if new information about risk or urgency emerges. Build a reclassification path rather than locking the initial assignment. Also avoid using this prompt as a gate that blocks low-priority work entirely; even low-tier tasks need processing, just with appropriate latency expectations. The classification should influence queue priority and resource allocation, not determine whether work happens at all.

This prompt template assigns a service-level agreement (SLA) tier to an incoming verification task. It is designed for operations teams running verification pipelines where cost, latency, and accuracy must be balanced against claim risk. The prompt expects a structured claim and its associated metadata, and it returns a classification that downstream systems can use for queue prioritization, resource allocation, and deadline enforcement. Do not use this prompt for real-time, user-facing decisions without a human-in-the-loop override for high-risk tiers.

textCopy
You are a verification operations classifier. Your task is to assign an SLA tier to the verification request described below. Use only the provided claim details, evidence summary, and organizational policy to make your determination.

INPUT:
Claim: [CLAIM_TEXT]
Claim Domain: [DOMAIN]
Claim Complexity Score: [COMPLEXITY_SCORE]
Available Evidence Count: [EVIDENCE_COUNT]
Evidence Recency (hours): [EVIDENCE_RECENCY_HRS]
Potential Harm if Unverified: [POTENTIAL_HARM_LEVEL]
Request Timestamp: [REQUEST_TIMESTAMP]

ORGANIZATIONAL SLA POLICY:
[SLA_POLICY_DOCUMENT]

OUTPUT_SCHEMA:
{
  "sla_tier": "CRITICAL | HIGH | STANDARD | LOW",
  "deadline_iso8601": "string",
  "review_depth": "DEEP | STANDARD | LIGHT",
  "escalation_triggers": ["string"],
  "routing_instruction": "AUTO_VERIFY | HUMAN_REVIEW | HYBRID",
  "classification_rationale": "string"
}

CONSTRAINTS:
- CRITICAL tier requires HUMAN_REVIEW routing and DEEP review depth.
- Claims with POTENTIAL_HARM_LEVEL of 'HIGH' cannot be classified below STANDARD.
- The deadline must be calculated from REQUEST_TIMESTAMP using the SLA policy durations.
- If EVIDENCE_COUNT is 0, routing must be HUMAN_REVIEW.
- Escalation triggers must reference specific conditions from the SLA policy.
- Do not invent evidence or assume claim veracity.

EXAMPLES:
[FEW_SHOT_EXAMPLES]

Now, classify the verification request.

To adapt this template, replace each square-bracket placeholder with data from your verification pipeline. The [SLA_POLICY_DOCUMENT] should contain the full text of your organization's SLA definitions, including tier criteria, deadline durations, and escalation rules. The [FEW_SHOT_EXAMPLES] placeholder is critical for consistent tier assignment; include at least two examples per tier, covering boundary cases where a claim could reasonably fall into adjacent tiers. Before deploying, validate the output against your schema and run a queue simulation to ensure that deadline-aware routing does not produce SLA breaches under load. For high-stakes domains, always route CRITICAL and HIGH tier classifications through a human approval step before the deadline is committed to a downstream system.

The SLA classification prompt is designed to sit at the entry point of a verification queue, immediately after claim extraction and before evidence retrieval or reviewer assignment. In a production harness, you call this prompt once per verification task, passing the extracted claim, its risk classification, the domain, and any known evidence availability flags as [INPUT]. The model returns a structured SLA tier, deadline, review depth requirements, and escalation triggers. This output must be validated before it touches any routing logic—an incorrect SLA assignment can silently downgrade a high-risk claim to a low-priority queue, causing SLA breaches that compound across the pipeline.

Wire the prompt into your application with a strict validation layer. Before the SLA output reaches your queue router, confirm that: (1) the returned SLA tier exists in your configured tier list, (2) the deadline is a valid ISO 8601 timestamp in the future, (3) the review depth field matches one of your predefined levels (e.g., 'surface', 'standard', 'deep'), and (4) escalation triggers are non-empty for any tier above 'low'. If validation fails, retry once with the same input and a stronger constraint instruction appended to [CONSTRAINTS]. If the second attempt also fails, route the task to a manual SLA assignment queue and log the failure for triage. For model choice, use a fast, cost-effective model (e.g., GPT-4o-mini, Claude Haiku) for this classification step—it's a structured output task that doesn't require deep reasoning, and latency here directly impacts your pipeline's end-to-end SLA budget.

Log every SLA classification decision with the claim ID, input risk level, assigned tier, deadline, and the model's raw response. This log becomes your audit trail when a reviewer misses a deadline and you need to determine whether the SLA was misassigned or the reviewer queue was overloaded. In your queue simulation tests, inject claims with known risk profiles and verify that SLA assignments don't drift under load. The most common production failure mode is SLA tier inflation—the model assigns a lower urgency tier than the claim's actual risk warrants because it overweights evidence availability and underweights potential harm. Mitigate this by running a weekly eval that compares SLA assignments against a golden set of claims with known correct tiers, and tune your [CONSTRAINTS] block to penalize under-classification more heavily than over-classification if your operational cost model supports it.