Risk Score Human Review Queue Routing Prompt

This prompt is designed for review operations teams who manage human-in-the-loop safety workflows and need to convert upstream safety classifier outputs into deterministic, auditable routing decisions. The core job-to-be-done is queue assignment: given a risk score, an uncertainty estimate, and a harm category from a classifier, the prompt produces a prioritized review queue assignment that respects specialized reviewer pools, balances load across available queues, and attaches SLA urgency based on harm severity. The ideal user is a safety platform engineer or operations lead integrating this prompt into an automated routing pipeline where classification has already occurred and the next step is deciding exactly which human reviewer or team should see the item and how quickly they must act.

This prompt is not a classifier. It assumes the classification step is complete and trustworthy. You should use it when your system already has a risk score with an associated uncertainty value and harm category label, and you need to apply routing rules that consider reviewer specialization (e.g., CSAM reviewers vs. violent content reviewers), current queue depth, business hours, and SLA tiers. The prompt is appropriate for production systems that require consistent, explainable routing decisions with an audit trail. It is not appropriate when the upstream classifier is unreliable, when you lack defined reviewer pools or SLAs, or when the volume is low enough that manual triage is sufficient. Do not use this prompt to perform the initial safety classification or to make the final content moderation decision—it only decides where and with what priority a human should review the item.

Before deploying this prompt, ensure you have defined your reviewer pools, their specializations, your SLA tiers by harm severity, and your load-balancing rules. The prompt template includes placeholders for these operational parameters. Wire the prompt into your application after the classifier returns its output and before the item enters any review queue. Validate the output against an expected schema that includes the assigned queue, priority level, SLA deadline, and routing rationale. Log every routing decision for auditability. In high-risk domains such as CSAM or imminent harm, configure the system to bypass queue depth limits and route directly to the highest-priority queue regardless of load. The next step after reading this section is to review the prompt template and adapt the routing rules to your specific operational topology.

This prompt template is designed to be called after an upstream safety classifier has produced a risk score, classification label, and confidence estimate for a user request. It does not perform the classification itself. Instead, it consumes the classifier's output and your operational routing rules to produce a structured queue assignment. The template uses square-bracket placeholders for every variable input, so you can wire it directly into your review orchestration system. Before deploying, ensure that the upstream classifier's output schema matches the fields referenced in the [CLASSIFIER_OUTPUT] placeholder.

textCopy
You are a review queue routing engine for a production AI safety system. Your job is to assign a single review queue and priority level for each request that has been flagged by the upstream safety classifier.

## INPUT
- Classifier Output: [CLASSIFIER_OUTPUT]
- User Request: [USER_REQUEST]
- Session Risk Score: [SESSION_RISK_SCORE]
- Available Queues: [AVAILABLE_QUEUES]
- Current Queue Depths: [QUEUE_DEPTHS]
- SLA Windows: [SLA_WINDOWS]

## ROUTING RULES
1. If the classifier's confidence is below [LOW_CONFIDENCE_THRESHOLD], route to the [HIGH_SCRUTINY_QUEUE] regardless of risk score.
2. If the risk score exceeds [HIGH_RISK_THRESHOLD], route to the [ESCALATION_QUEUE] with priority `critical`.
3. If the harm category is in [SPECIALIZED_CATEGORY_LIST], route to the corresponding specialized reviewer pool: [SPECIALIZED_POOL_MAPPING].
4. For all other cases, route to the [GENERAL_REVIEW_QUEUE] with priority determined by the risk score and SLA window.
5. Apply load-balancing: if the target queue depth exceeds [MAX_QUEUE_DEPTH], reassign to the next available queue with matching specialization, or escalate to the [OVERFLOW_QUEUE] if no matching queue is available.

## OUTPUT SCHEMA
Return a single JSON object with this exact structure:
{
  "queue_assignment": {
    "queue_id": "string",
    "queue_name": "string",
    "priority": "critical | high | medium | low",
    "sla_deadline": "ISO 8601 timestamp",
    "routing_rule_applied": "string",
    "load_balance_override": "boolean",
    "override_reason": "string | null"
  },
  "review_context": {
    "risk_score": "number",
    "confidence": "number",
    "harm_category": "string",
    "session_risk_score": "number",
    "classification_summary": "string"
  },
  "audit_trail": {
    "routing_timestamp": "ISO 8601 timestamp",
    "classifier_version": "string",
    "routing_engine_version": "string"
  }
}

## CONSTRAINTS
- Assign exactly one queue. Do not return multiple queue options.
- The `routing_rule_applied` field must cite the specific rule number from the ROUTING RULES section.
- If load balancing overrides the primary routing rule, set `load_balance_override` to `true` and explain in `override_reason`.
- The `sla_deadline` must be calculated from the current time plus the SLA window for the assigned priority and queue.
- Do not include commentary outside the JSON object.

Adapt this template by replacing each square-bracket placeholder with data from your upstream safety classifier and queue management system. The [CLASSIFIER_OUTPUT] placeholder expects a structured object containing at minimum risk_score, confidence, and harm_category. If your classifier produces additional fields, include them in the review_context object. The [AVAILABLE_QUEUES] placeholder should contain an array of queue objects with queue_id, queue_name, specialization, and active fields. Test the template with edge cases where confidence is near the threshold boundary, where all specialized queues are at capacity, and where the session risk score contradicts the single-turn classifier output. Validate that the output JSON strictly conforms to the schema before passing it to your review queue dispatcher.

This prompt is designed to sit between a safety classifier and a human review queue management system. It takes structured risk assessment data—including confidence scores, harm categories, and severity levels—and produces a prioritized routing decision that determines which queue a case should enter, what priority it should receive, and which reviewer pool is best suited to handle it. The harness must treat this as a high-stakes decision point: routing errors can cause high-severity cases to languish in low-priority queues or flood specialist reviewers with false positives.

Input validation is the first harness layer. Before calling the model, validate that incoming risk scores are numeric and within expected ranges, confidence values are present and not null, and harm category labels match your taxonomy. Reject malformed inputs with a structured error rather than letting the model hallucinate routing decisions from garbage data. Output validation after the model responds should check that the assigned queue exists in your routing table, the priority level is one of your defined tiers, and any SLA timestamps are parseable and in the future. If validation fails, retry once with the validation errors appended to the prompt as [CONSTRAINTS] feedback. After a second failure, route to a default high-priority queue with a routing_failure flag for manual triage.

Model choice and latency matter here. This prompt benefits from models with strong instruction-following and structured output capabilities. For high-throughput review pipelines, consider a fast model for clear-cut cases and escalate to a more capable model only when confidence scores fall in the [LOW_CONFIDENCE_THRESHOLD] to [HIGH_CONFIDENCE_THRESHOLD] band. Logging must capture the full input payload, the model's routing decision, the validation result, and the final queue assignment. This audit trail is essential for measuring queue balance, SLA compliance, and reviewer workload distribution over time. Human override should always be available: reviewers must be able to re-queue or re-prioritize cases, and those overrides should feed back into your evaluation dataset for future prompt improvements.

What to avoid: Do not hardcode queue names or reviewer pool assignments in the prompt itself—use the [QUEUE_CONFIG] and [REVIEWER_POOLS] placeholders to inject current routing tables at runtime. Do not let the model invent new priority levels or queues that don't exist in your system. Do not skip the output validation step; a hallucinated queue name that silently drops cases is a production incident waiting to happen. Start with a dry-run mode that logs routing decisions without actually enqueueing cases, compare against human routing judgments for at least 500 cases, and only then enable live queue assignment with monitoring on queue depth, time-to-first-review, and misrouted case rates.