Review Item Automated Pre-Screening Prompt for Low-Risk Filtering

This prompt is designed for operations leads and platform engineers who manage high-volume review queues where reviewer fatigue is a measurable problem. The core job-to-be-done is filtering incoming items before they reach a human: the prompt analyzes each item and makes a structured decision to either auto-resolve it as low-risk and routine, or escalate it to a human reviewer with clear reasoning. The goal is to let humans focus on ambiguous, high-stakes, or novel items while the AI handles clear-cut cases. You should use this prompt when you have a defined set of low-risk resolution patterns, a queue of structured or semi-structured items, and a tolerance for some false positives (items escalated unnecessarily) but zero tolerance for false negatives (high-risk items incorrectly marked as low-risk).

This prompt is not a replacement for a full triage system. Do not use it when the cost of a single false negative is catastrophic, when review items lack sufficient structure for reliable classification, or when low-risk patterns are not yet well-defined and stable. The prompt works best when paired with a human-in-the-loop override mechanism: every auto-resolved item should be logged with its decision rationale, and a random sample should be audited to detect pattern drift. Before deploying, you must define your [RISK_LEVEL] taxonomy, your [LOW_RISK_PATTERNS] catalog, and your escalation criteria. Without these, the prompt will produce inconsistent decisions that erode trust in the automation.

Start by running this prompt in shadow mode against your existing queue for at least one full review cycle. Compare its decisions against human reviewer outcomes to calibrate your false-negative rate. Only enable auto-resolution after you have evidence that the prompt is not passing through items that require human judgment. The next section provides the copy-ready template you will adapt with your specific risk patterns and output schema.

This prompt template is designed to be the core instruction set for an automated pre-screening system. Its job is to analyze a single review item and make a binary recommendation: auto-resolve if the item is low-risk and matches a known, safe pattern, or escalate to human review if any risk factor, ambiguity, or exception is detected. The template uses square-bracket placeholders so you can inject your specific risk categories, resolution policies, and output format requirements without rewriting the core logic. The primary goal is to reduce reviewer fatigue by safely filtering out the noise.

codeCopy
You are an automated pre-screening agent for a high-volume review queue. Your task is to analyze a review item and recommend whether it can be safely auto-resolved or must be escalated to a human reviewer. Your primary directive is safety: when in doubt, escalate.

INPUT ITEM:
[REVIEW_ITEM]

PRE-SCREENING RULES:
[RULES]

LOW-RISK AUTO-RESOLUTION PATTERNS:
[LOW_RISK_PATTERNS]

ESCALATION CRITERIA (escalate if ANY are true):
[ESCALATION_CRITERIA]

OUTPUT SCHEMA (strict JSON):
{
  "decision": "AUTO_RESOLVE" | "ESCALATE",
  "confidence": 0.0-1.0,
  "matched_pattern": "string | null",
  "escalation_reasons": ["string", ...],
  "recommended_action": "string | null",
  "evidence_summary": "string"
}

CONSTRAINTS:
- If the item matches a LOW_RISK_PATTERN and triggers NO ESCALATION_CRITERIA, set decision to "AUTO_RESOLVE".
- If ANY ESCALATION_CRITERIA are met, or if the item does not cleanly match a pattern, set decision to "ESCALATE".
- The "recommended_action" field must be populated ONLY for AUTO_RESOLVE decisions.
- The "escalation_reasons" field must be populated ONLY for ESCALATE decisions.
- The "evidence_summary" must cite specific parts of the INPUT ITEM that led to the decision.
- If confidence is below [CONFIDENCE_THRESHOLD], you must ESCALATE.

To adapt this template, start by defining your [LOW_RISK_PATTERNS] and [ESCALATION_CRITERIA] with concrete, testable rules. For example, a low-risk pattern might be "password reset request with valid account ID and no recent suspicious activity," while an escalation criterion could be "item mentions a financial transaction over $500" or "item contains a legal threat." The [RULES] placeholder is for any global policies, like data handling or tone. After copying the template, the next critical step is to build a validation harness around the JSON output to ensure the decision field is never null and that the logic of the constraints is enforced before any action is taken.

Integrating the Review Item Automated Pre-Screening Prompt into a production workflow requires treating it as a deterministic filter within a broader triage pipeline, not a standalone decision engine. The prompt's primary job is to identify items that are safe to auto-resolve or clearly require human review, reducing queue volume without introducing unacceptable risk. The implementation harness must enforce a strict contract: the model receives a structured review item, returns a structured decision, and the application layer validates that decision before any action is taken. This means the prompt is one component in a system that includes input validation, output schema enforcement, confidence threshold gating, and an audit trail.

The application should call the model with the prompt template, substituting the [REVIEW_ITEM] placeholder with a JSON object containing at minimum item_id, summary, evidence, and proposed_action. The model's response must be parsed against a strict schema expecting decision (one of AUTO_RESOLVE, ESCALATE, UNCLEAR), rationale, risk_factors (an array of strings), and confidence (a float between 0.0 and 1.0). Implement a post-processing validator that rejects any response failing schema compliance, missing required fields, or containing a confidence value below a configurable threshold (start with 0.85 for low-risk domains). Failed validations should trigger a single retry with the same input and a stronger instruction to conform to the output schema. After one retry, if validation still fails, the item must be routed to the human review queue with a pre_screen_error flag for diagnosis.

The most dangerous failure mode is a false-negative pass: the model returns AUTO_RESOLVE with high confidence for an item that actually required human review. To mitigate this, deploy a shadow evaluation pipeline that sends a sample of auto-resolved items to human reviewers and compares their decisions against the model's. Track the false-pass rate and set an operational threshold (e.g., <2% false passes) that triggers automatic circuit-breaking—if exceeded, the system stops auto-resolving and routes all items to human review until the root cause is diagnosed. Log every decision with the full prompt, response, validator results, and final routing action. This audit trail is essential for debugging drift, calibrating confidence thresholds, and demonstrating compliance during governance reviews. Never allow the model to execute the proposed action directly; the harness must treat the pre-screen decision as a routing hint, not an authorization.