Enum-Controlled Classification Output Prompt

This prompt is for product teams and AI engineers building classification pipelines where the output must be restricted to a predefined set of labels. Use it when a free-text or open-ended classification would break downstream automation, routing logic, or database constraints. Common production scenarios include support ticket triage into a fixed queue taxonomy, content moderation with a controlled policy label set, intent detection for a finite set of handler functions, and compliance classification where only specific regulatory categories are valid. If your downstream system has a database column with a CHECK constraint, an API endpoint that validates against an enum, or a routing table that maps labels to actions, this prompt is designed for you.

The prompt template enforces three production-critical behaviors: strict enum membership so the model never emits a label outside the allowed set, explicit fallback rules that define what happens when the input is ambiguous or out of scope, and a confidence threshold that rejects low-certainty classifications instead of guessing. The template includes a dedicated [FALLBACK_LABEL] placeholder and a [CONFIDENCE_THRESHOLD] instruction so that ambiguous inputs produce a predictable, auditable result rather than a hallucinated label. This matters in production because a single out-of-vocabulary classification can silently break downstream consumers, corrupt analytics, or route a high-priority item to the wrong team.

Do not use this prompt when the classification space is unbounded, when labels need to be discovered from the data, or when the output requires natural language justification alongside the label. For open-ended categorization, use a clustering or extraction prompt instead. For workflows that need both a label and an explanation, consider a two-step pipeline: classify with this prompt first, then generate an explanation conditioned on the assigned label. Also avoid this prompt when the enum set changes frequently—each change requires prompt template updates and regression testing against the new label set. If your classification task involves high-stakes decisions in regulated domains such as healthcare triage or financial fraud determination, pair this prompt with human review and evidence grounding; the confidence threshold alone is not a safety guarantee.

This template enforces strict enum-controlled classification. The model must select exactly one label from a closed set, provide a confidence score, and handle ambiguous or out-of-scope inputs through a defined fallback path. Replace every square-bracket placeholder with your domain-specific values before deploying. The prompt is designed to be used as a system message in a single-turn classification call, not as part of a multi-turn conversation.

textCopy
You are a classification system that assigns exactly one label from a controlled vocabulary to each input. You must never generate labels outside the allowed set.

## Allowed Labels
[LABEL_ENUM_SET]

## Classification Rules
- Select the single best label from the allowed set above.
- If multiple labels could apply, choose the most specific one.
- If no label clearly applies, use the fallback label: [FALLBACK_LABEL].
- Do not invent new labels, combine labels, or return free-text explanations as the label.

## Confidence Scoring
- Return a confidence score between 0.0 and 1.0.
- Score above [HIGH_CONFIDENCE_THRESHOLD] means the classification is reliable.
- Score below [LOW_CONFIDENCE_THRESHOLD] means the classification is uncertain and should trigger human review.
- If using the fallback label, set confidence to 0.0.

## Output Format
Return ONLY a valid JSON object with exactly these fields:
{
  "label": "<selected label from allowed set>",
  "confidence": <float between 0.0 and 1.0>,
  "rationale": "<one sentence explaining the classification>"
}

## Constraints
- Do not wrap the JSON in markdown fences or add surrounding text.
- Do not include fields other than label, confidence, and rationale.
- The label field must be an exact string match to one entry in the allowed set.
- The confidence field must be a number, not a string.

## Input to Classify
[INPUT_TEXT]

Adaptation guidance: Replace [LABEL_ENUM_SET] with your comma-separated or bulleted list of allowed labels. Set [FALLBACK_LABEL] to a label like "other", "unclassified", or "needs_review" that your downstream system can route appropriately. Tune [HIGH_CONFIDENCE_THRESHOLD] and [LOW_CONFIDENCE_THRESHOLD] based on your tolerance for false positives versus false negatives—typical starting values are 0.85 and 0.60 respectively. Replace [INPUT_TEXT] at runtime with the text to classify. If you need multi-label classification, this template is the wrong starting point; use a structured output prompt with an array field instead.

Validation and eval setup: Before shipping, build a validator that checks: (1) the label field is an exact string match to your allowed enum set, (2) confidence is a float within [0.0, 1.0], (3) the JSON parses without errors, and (4) no extra fields are present. Run this prompt against a golden dataset of at least 50 examples covering clear cases, edge cases, and deliberately out-of-scope inputs. Measure enum violation rate, fallback label usage on in-scope inputs, and confidence calibration. If enum violations exceed 1% in testing, add explicit negative examples to the prompt or tighten the constraints section.

When to escalate: If the model returns the fallback label with confidence above 0.0, or if confidence falls below your low threshold on a high-stakes classification, route the item to a human review queue. Do not silently accept low-confidence classifications in workflows where incorrect labels trigger downstream actions like routing, blocking, or financial decisions. For regulated domains, log the full prompt, response, and validator output for audit.

The Enum-Controlled Classification Output Prompt is designed to be the final classification step in a pipeline, not a standalone chat interaction. In production, you will typically call this prompt after upstream retrieval, extraction, or summarization steps have produced the [INPUT] text. The prompt's job is to map that input to exactly one value from the [ALLOWED_ENUMS] set and return a structured JSON object with the classification, confidence score, and reasoning. Do not expose this prompt directly to end users; it should sit behind an API endpoint or internal service that controls the enum set, validates the output, and handles failures before any downstream system consumes the classification result.

Wire the prompt into your application with a thin service layer that performs pre-call and post-call checks. Before calling the model, validate that [ALLOWED_ENUMS] is a non-empty array of strings, that [INPUT] is not null or whitespace, and that [CONFIDENCE_THRESHOLD] is a float between 0.0 and 1.0. After receiving the model response, parse the JSON and run these validators in order: (1) confirm the classification field is present and its value is an exact string match to one of the allowed enums—reject any output where the model invents a new label or returns a near-match; (2) confirm confidence is a float between 0.0 and 1.0; (3) if confidence is below [CONFIDENCE_THRESHOLD], route the item to a human review queue or a fallback classifier rather than accepting a low-confidence automated decision; (4) log every classification result with the input hash, model version, enum set, confidence, and timestamp for auditability. For high-risk domains such as healthcare triage, legal intake, or financial compliance, always require human review when confidence falls below the threshold or when the model returns the [FALLBACK_LABEL].

Choose your model based on the complexity of your classification task and latency budget. For simple enum sets under 20 labels with clear definitions, a fast model like GPT-4o-mini, Claude 3.5 Haiku, or a fine-tuned open-weight model will suffice. For ambiguous inputs, overlapping label definitions, or enum sets exceeding 50 values, use a more capable model like GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro. Implement a retry strategy with a maximum of two retries on validation failure: on the first retry, append the validation error message to the prompt context; on the second retry, explicitly instruct the model to return the [FALLBACK_LABEL] if it cannot produce a valid enum. If both retries fail, log the failure, return the fallback label with confidence 0.0, and alert the operations team. Never silently accept an invalid classification—downstream routing, billing, or compliance systems will break on unexpected values.

For observability, instrument every classification call with a trace that captures the input length, enum set size, model used, latency, confidence score, retry count, and final classification. Set up an eval harness that runs weekly against a golden dataset of 200+ labeled examples covering every enum value, edge cases, and deliberate boundary violations. Measure exact-match accuracy, out-of-vocabulary rejection rate, and confidence calibration. When you update the enum set, re-run the eval suite before deploying the change and version the prompt alongside the enum definition in your prompt registry. If your classification pipeline feeds into automated actions—such as ticket routing, alert escalation, or content moderation—add a circuit breaker that halts automation if the rate of fallback classifications or validation failures exceeds 5% in a rolling window.