Classification Rejection Prompt for Edge Cases

This prompt is for safety and reliability engineers who need a hard boundary around their classification system. Its job is not to classify an input, but to decide whether classification should be attempted at all. Use it when the cost of a wrong answer—even a low-confidence one—is higher than the cost of refusing to answer. Typical triggers include inputs that are clearly out-of-distribution, adversarial, nonsensical, or fall into a category your system is contractually or regulatorily prohibited from handling. The ideal user is an infrastructure engineer wiring this rejection layer as a preflight check before any downstream classifier, tool, or agent is invoked.

Do not use this prompt when you need a best-effort guess. If your system can tolerate low-confidence routing to a general queue or a clarifying question, use a confidence scoring prompt with a fallback path instead. This prompt is for binary gating: proceed or reject. It is appropriate for regulated domains, safety-critical workflows, and multi-tenant platforms where one tenant's valid input is another tenant's policy violation. The prompt requires a defined [SCOPE_DEFINITION] that explicitly lists what is in-scope, and a [REJECTION_CATEGORIES] list with concrete examples of what should be rejected and why. Without these, the model will default to permissive behavior and the rejection layer becomes useless.

Before deploying, build a test harness with known out-of-distribution inputs, adversarial examples, and boundary cases that sit just inside and outside your scope. Measure both false rejections (blocking valid work) and false admissions (allowing what should have been stopped). If either rate is unacceptable, tighten your scope definitions or add few-shot examples of borderline cases. The next section provides the prompt template you can adapt directly into your preflight pipeline.

This prompt is designed for safety and reliability engineers who need a classification system that knows when to say no. Instead of forcing a label on every input, it evaluates whether the input falls within the system's supported domain and rejects it with a structured reason when it does not. The template uses square-bracket placeholders so you can adapt the domain boundaries, rejection categories, and output schema to your specific taxonomy and risk tolerance.

textCopy
You are a classification rejection system. Your job is to decide whether an input can be reliably classified or must be rejected.

## Supported Classification Scope
[DOMAIN_DESCRIPTION]

## Rejection Categories
You may reject an input for any of the following reasons. Choose the most specific reason that applies:
[REJECTION_REASONS]

## Input
[INPUT]

## Instructions
1. Determine whether the input falls within the supported classification scope.
2. If the input is within scope, output the classification result with confidence.
3. If the input is outside scope, ambiguous beyond resolution, adversarial, or otherwise unclassifiable, reject it.
4. For rejections, provide the specific rejection reason and cite the evidence from the input that triggered the rejection.
5. Do not guess. Do not return a low-confidence classification when a rejection reason applies.

## Output Schema
Respond with a single JSON object matching this schema:
{
  "decision": "classify" | "reject",
  "classification": {
    "label": "string, required if decision is classify",
    "confidence": "number between 0.0 and 1.0, required if decision is classify"
  },
  "rejection": {
    "reason": "string from rejection categories, required if decision is reject",
    "evidence": "string quoting the specific part of the input that triggered rejection, required if decision is reject",
    "suggested_action": "string describing what should happen next, required if decision is reject"
  }
}

## Constraints
[CONSTRAINTS]

## Examples
[EXAMPLES]

To adapt this template, start by defining your domain boundaries in [DOMAIN_DESCRIPTION]. Be explicit about what is in scope and what is out of scope—vague boundaries produce inconsistent rejections. Populate [REJECTION_REASONS] with a concrete list such as out-of-domain topic, adversarial input, underspecified request, conflicting signals, or unsupported language. Add [CONSTRAINTS] for any additional rules like maximum confidence thresholds, required fields, or prohibited outputs. Include [EXAMPLES] with at least three pairs showing correct classification and correct rejection decisions. Before deploying, run this prompt against a held-out set of known out-of-distribution inputs and verify that the rejection rate matches your expectations—silent misclassifications on edge cases are the failure mode this prompt exists to prevent.

The Classification Rejection Prompt is not a standalone classifier. It is a safety gate that sits between your primary classification system and the downstream handler. Wire it so that every classification attempt with confidence below a defined threshold passes through this rejection check before any action is taken. The prompt should receive the original input, the primary classifier's top label and confidence score, and any relevant context that might explain why the input is difficult. Its job is to produce a binary decision—accept or reject—along with a structured rejection reason and a recommended fallback action. This harness must treat a missing or malformed rejection response as a rejection, not a pass-through.

Implement this as a post-classification middleware step. After your primary classifier returns a label and confidence, check the confidence against your system's threshold. If it falls below, call the rejection prompt with the input, the low-confidence classification result, and a [CONFIDENCE_THRESHOLD] parameter. Validate the response against a strict schema: require a decision field with enum values ACCEPT or REJECT, a rejection_reason string drawn from a predefined taxonomy (e.g., out_of_distribution, ambiguous_input, adversarial_potential, insufficient_context), and a fallback_action enum (escalate_to_human, ask_clarification, route_to_general_queue, block). If the response fails schema validation, retry once with a repair prompt. If it fails again, default to REJECT with reason validation_failure and escalate to human review. Log every rejection decision with the input hash, classifier output, rejection reason, and fallback action for audit and drift analysis.

Model choice matters here. Use a model with strong instruction-following and low refusal rates on safety-adjacent tasks—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller models that may conflate rejection with content refusal. Set temperature=0 for deterministic outputs. For high-throughput systems, batch rejection checks asynchronously and set a strict timeout (e.g., 2 seconds). If the rejection prompt times out, treat it as a rejection and route to the general fallback queue. Never let a rejection check become a bottleneck that silently drops inputs. Build an eval harness that tests this prompt against a curated set of known out-of-distribution inputs, adversarial examples, and boundary cases. Measure rejection recall (did it catch what it should?), false rejection rate (did it block valid inputs?), and schema compliance rate. Run these evals on every prompt change before deployment.