Batch Safety Screening Prompt Template

This prompt is designed for platform operators and safety engineers who need to classify large volumes of user-generated content against a defined safety taxonomy before the content enters downstream workflows. The primary job-to-be-done is consistent, high-throughput policy enforcement across a queue of messages, posts, or user inputs. It is ideal when you have a pre-defined harm taxonomy and policy categories, and you need batch-level quality metrics rather than real-time, per-item latency optimization. The batch approach optimizes for throughput and consistency, making it suitable for offline processing, backfills, or asynchronous moderation pipelines where a slight delay is acceptable in exchange for uniform taxonomy application.

You should use this prompt when you have a static or slowly changing set of content that can be grouped for processing, and when your evaluation criteria include aggregate metrics like inter-annotator agreement across the batch or distribution of classification labels. It is not a replacement for real-time streaming safety interrupts, which require low-latency, per-item decisions and early-abort capabilities. Similarly, it is not designed for single-turn refusal prompts where the model must generate a user-facing response. For high-severity edge cases—such as content involving child safety, imminent harm, or regulated domains—this batch classifier should flag items for human review rather than making a final enforcement decision autonomously.

Before using this prompt, ensure you have a finalized harm taxonomy with clear category definitions, severity levels, and policy mappings. The prompt template includes placeholders for these definitions, and ambiguous or overlapping categories will degrade classification consistency. After running the batch, validate the output against a golden dataset of labeled examples to measure precision, recall, and over-refusal rates. Use the batch-level quality metrics to tune category definitions and confidence thresholds before promoting the prompt to production. If your use case involves adversarial users actively probing for policy gaps, pair this batch classifier with a real-time injection detection system and a multi-turn probing monitor.

This prompt template is designed for platform operators processing high-volume content queues where per-request latency matters less than throughput, consistency, and auditability. It accepts a batch of inputs and returns structured classifications for each, applying the same taxonomy and severity criteria across all items. Use this when you need to screen user-generated content, incoming messages, or document submissions before they reach downstream models or human reviewers. Do not use this for real-time streaming classification where per-item latency is critical—use a single-item classification prompt with streaming support instead.

textCopy
You are a safety classification system processing content in batch mode. Your task is to evaluate each input in the provided batch against the safety taxonomy below and return structured classifications for every item. Apply the taxonomy consistently across all inputs. Do not skip any item. Do not reorder items.

## SAFETY TAXONOMY
[TAXONOMY]

## SEVERITY LEVELS
[SEVERITY_LEVELS]

## CLASSIFICATION RULES
1. Evaluate each input independently against all taxonomy categories.
2. Assign the highest applicable severity level per category.
3. If an input spans multiple categories, flag all relevant categories.
4. Mark items as [UNCERTAIN] when classification confidence is below the threshold.
5. Preserve the original item order in the output.

## CONFIDENCE THRESHOLD
[CONFIDENCE_THRESHOLD]

## INPUT BATCH
[BATCH_INPUTS]

## OUTPUT FORMAT
Return a JSON object with the following structure:
{
  "batch_id": "[BATCH_ID]",
  "processed_at": "ISO timestamp",
  "total_items": integer,
  "results": [
    {
      "item_index": integer,
      "input_hash": "string",
      "classifications": [
        {
          "category": "string",
          "severity": "string",
          "confidence": float,
          "flags": ["string"]
        }
      ],
      "overall_risk": "none|low|medium|high|critical",
      "requires_review": boolean,
      "uncertain": boolean
    }
  ],
  "batch_metrics": {
    "high_risk_count": integer,
    "review_required_count": integer,
    "uncertain_count": integer,
    "processing_time_ms": integer
  }
}

## CONSTRAINTS
[CONSTRAINTS]

## EXAMPLES
[EXAMPLES]

To adapt this template, replace each square-bracket placeholder with your operational configuration. [TAXONOMY] should contain your complete harm category definitions with clear inclusion and exclusion criteria—ambiguous taxonomy definitions are the primary cause of inconsistent batch classifications. [SEVERITY_LEVELS] must define each tier with concrete examples of what qualifies, not just labels. [BATCH_INPUTS] should be a JSON array of input objects, each with a unique identifier and the content to classify. [CONFIDENCE_THRESHOLD] sets the floor for automated decisions; items below this threshold should route to human review. [EXAMPLES] should include at least three few-shot examples covering clear violations, benign content, and boundary cases to anchor the model's calibration. [CONSTRAINTS] can specify rate limits, output size caps, or domain-specific exclusions. Before deploying, validate that your taxonomy categories are mutually exclusive where possible and that severity levels map cleanly to your downstream enforcement actions—misalignment here creates operational debt that compounds with volume.

The batch safety screening prompt is designed to be called from a queue-processing worker, an API endpoint that accepts lists of content items, or a scheduled job that pulls from a moderation backlog. Because this prompt processes multiple items in a single call, the application layer must handle input batching, output parsing, and per-item result distribution. The prompt expects a structured list of content items with unique identifiers; the application should assign these IDs before calling the model and use them to map results back to source records. Do not rely on the model to preserve item ordering—always join on the provided IDs.

The implementation harness should include a pre-call validator that checks each content item for required fields (id, content, content_type) and rejects malformed batches before they reach the model. After the model responds, a post-call parser must extract the JSON array from the response, validate each result object against the expected schema (requiring id, classification, confidence, policy_categories, and severity fields), and flag any items where the model returned an unrecognized ID or omitted required fields. Items that fail post-call validation should be retried individually or routed to a human review queue. For high-throughput systems, implement a batch-level quality gate: if more than 5% of items in a batch fail validation or return low-confidence classifications, quarantine the entire batch for review rather than auto-accepting partial results.

Retry logic should be conservative. If the model returns malformed JSON, retry once with a simplified prompt that requests only the JSON array without additional commentary. If a second attempt fails, log the raw response and escalate the batch. For individual items with confidence scores below a configurable threshold (e.g., < 0.7), route those items to a human review queue with the model's classification and evidence attached. Logging must capture: batch ID, model version, prompt template version, item count, processing latency, validation failure count, low-confidence item count, and any items escalated for human review. These logs feed into the evaluation framework for measuring batch consistency and edge-case preservation described in the topic overview.

Model choice matters for batch throughput and consistency. Use models with strong JSON-mode or structured-output support (e.g., GPT-4o with response_format, Claude 3.5 Sonnet with tool-use mode) to reduce parsing failures. For cost-sensitive, high-volume pipelines, consider routing clear-cut items through a smaller classifier model and reserving the full batch prompt for ambiguous or edge-case content. Human review integration should expose the model's classification, confidence score, evidence excerpts, and policy citations in a review UI that allows accept, override, or reclassify actions. Track reviewer decisions to build a feedback dataset for future prompt tuning and threshold calibration.

Avoid wiring this prompt directly into a synchronous user-facing request path. Batch processing implies asynchronous handling—return an acknowledgment to the submitting system and process results via webhook, callback, or status polling. Never expose raw model outputs to end users without review gating when the content involves regulated domains or high-severity harm categories. The next step after implementing this harness is to run the evaluation framework against a labeled test set to establish baseline accuracy, batch consistency, and false-positive rates before promoting to production.