Internal Review Queue Annotation Prompt Template

This prompt is designed for trust-and-safety operations where every refused user request must be reviewed by a human analyst. Instead of forcing analysts to start from a blank ticket, the model pre-annotates the refused request with a structured brief: policy tags, a risk score, verbatim evidence excerpts from the user's input, references to similar past cases, and a recommended disposition. The primary job-to-be-done is reducing analyst decision fatigue and accelerating queue throughput by providing a consistent, data-rich starting point for human judgment. The ideal user is a trust-and-safety analyst, a policy operations lead, or an engineering team building an internal review tool. You need a stable, well-documented policy taxonomy and a queue of refused requests that are already flagged by an upstream safety classifier.

Deploy this prompt when your review queue is large enough that annotation inconsistency and analyst burnout are measurable problems. It is most effective when integrated into a review tool that can display the model's structured output alongside the original request, allowing the analyst to confirm, correct, or escalate the annotation with a single click. The prompt requires several inputs to function correctly: the full text of the user's refused request, the specific policy clause that triggered the refusal, a defined risk score scale, and a schema for the desired output. You should not use this prompt to auto-resolve tickets without human review. The output is a decision-support artifact, not a final determination. Using it to automatically close tickets bypasses the human judgment step and creates an unacceptable risk of incorrect enforcement.

Avoid this prompt if your policy taxonomy is in flux, as the model will produce annotations that lag behind your latest policy changes. It is also a poor fit for low-risk or ambiguous requests where a simple form response is sufficient; the overhead of structured annotation is wasted on cases that don't require deep analysis. Finally, do not use this prompt in isolation. It must be part of a larger harness that logs the analyst's final decision, compares it to the model's recommendation, and feeds discrepancies back into a dataset for improving the prompt or fine-tuning a model over time. The next step after reading this section is to review the prompt template itself and map its placeholders to the fields in your internal review tool.

This template is designed to be wired directly into your internal review queue system. When a new refused request enters the queue, this prompt runs automatically to pre-annotate the item, giving your trust-and-safety analysts a structured head start. The prompt expects the raw user request, the refusal reason already generated, and any relevant session context. It then produces a structured annotation that includes policy tags, a risk score, evidence excerpts, similar case references, and a recommended disposition. The goal is to reduce analyst triage time and improve consistency across reviewers.

codeCopy
You are an expert trust-and-safety annotation assistant. Your task is to pre-annotate a refused user request for human review. You must produce a structured, evidence-backed annotation that helps a human analyst make a final decision quickly and consistently.

## INPUT
[USER_REQUEST]
[REFUSAL_REASON]
[SESSION_CONTEXT]
[POLICY_LIBRARY]
[CASE_HISTORY]

## OUTPUT_SCHEMA
Return a single JSON object with the following fields. Do not include any text outside the JSON.

{
  "policy_tags": [
    {
      "policy_id": "string (from POLICY_LIBRARY)",
      "policy_name": "string",
      "violation_type": "confirmed | suspected | borderline",
      "confidence": 0.0-1.0
    }
  ],
  "risk_score": {
    "overall": 0.0-1.0,
    "breakdown": {
      "severity": 0.0-1.0,
      "immediacy": 0.0-1.0,
      "user_history_escalation": 0.0-1.0
    }
  },
  "evidence_excerpts": [
    {
      "source": "user_request | session_context",
      "text": "string (exact quote)",
      "policy_tag_index": 0 (index into policy_tags array),
      "relevance": "direct | supporting | contextual"
    }
  ],
  "similar_cases": [
    {
      "case_id": "string (from CASE_HISTORY)",
      "similarity_reason": "string",
      "disposition": "string"
    }
  ],
  "recommended_disposition": "uphold_refusal | overturn_refusal | escalate | request_clarification",
  "disposition_rationale": "string (2-4 sentences explaining the recommendation)",
  "analyst_notes": "string (any additional context, ambiguities, or edge-case flags the analyst should consider)",
  "requires_legal_review": true | false,
  "requires_urgent_action": true | false
}

## CONSTRAINTS
1. Only tag policies that exist in POLICY_LIBRARY. Do not invent policy names or IDs.
2. Evidence excerpts must be exact quotes from the input. Do not paraphrase.
3. If no similar cases exist in CASE_HISTORY, return an empty array for similar_cases.
4. If the request is ambiguous, set recommended_disposition to "request_clarification" and explain what is unclear in disposition_rationale.
5. Risk scores must be calibrated: a score above 0.8 should indicate a clear, severe violation requiring immediate action.
6. Do not make a final decision. Your annotation is advisory. The human analyst owns the disposition.
7. If the refusal reason appears inconsistent with the user request, flag this in analyst_notes.

To adapt this template for your environment, replace the square-bracket placeholders with your actual data sources. [POLICY_LIBRARY] should contain your organization's policy definitions with IDs, names, and full policy text. [CASE_HISTORY] should contain a set of previously reviewed cases with their dispositions. If you don't have a case history yet, remove the similar_cases field from the output schema or set it to always return an empty array. The risk score breakdown fields can be adjusted to match your internal risk taxonomy. Before deploying, run this prompt against a golden set of 20-30 previously reviewed cases and compare the model's annotations against the human decisions. Measure agreement on policy tags, risk score calibration, and disposition recommendations. Flag any systematic disagreements for prompt refinement.

This prompt is designed to be called programmatically within a review queue pipeline, not used as a one-off chat interaction. When a user request is refused by the primary AI system, the refused request, the refusal response, and the session context are pushed into an internal review queue. Before a human analyst opens the case, this prompt is executed to pre-annotate the entry. The structured output reduces analyst triage time and ensures consistent metadata tagging across the queue. The prompt expects the raw refused request text, the refusal reason emitted by the system, the applicable policy clauses, and any relevant conversation history as input variables.

The implementation harness should enforce strict input validation before calling the model. The [REQUEST_TEXT] and [REFUSAL_REASON] fields must be non-empty strings. The [POLICY_CLAUSES] field should be a list of policy identifiers drawn from a controlled vocabulary maintained in your policy management system; reject any input that references unknown policies. The [SESSION_CONTEXT] field is optional but strongly recommended for multi-turn cases. On the output side, validate the JSON schema before the annotation enters the queue. Required fields include policy_tags, risk_score, evidence_excerpts, and recommended_disposition. If the model returns a malformed JSON object, use a repair prompt or a retry with stricter formatting instructions before falling back to a human-only review flag. Log every annotation attempt—including parse failures, schema violations, and retries—so the feedback loop can identify brittle cases.

The analyst feedback loop is the most critical part of this harness. After a human reviewer corrects or confirms the pre-annotation, the corrected annotation must be written back to a dataset that pairs the original prompt input with the human-corrected output. This dataset becomes the foundation for few-shot examples, fine-tuning data, and regression tests. Run a weekly eval comparing model annotations against human-corrected annotations on held-out cases to measure policy_tag agreement, risk_score mean absolute error, and recommended_disposition accuracy. If agreement drops below a defined threshold—typically 90% for policy tags in high-stakes queues—trigger a review of recent false positives and update the prompt's few-shot examples or policy definitions. Do not ship prompt changes to the annotation pipeline without running the updated prompt against the golden dataset of human-corrected cases.