Strict Enum Control Prompt for Status Field Outputs

This prompt is designed for product teams and backend engineers who need to classify unstructured text into a predefined set of status, category, or label values, where any out-of-vocabulary output will break downstream automation. The core job-to-be-done is turning a messy natural language input into a single, valid enum member from a controlled vocabulary, wrapped in a predictable JSON object. The ideal user is an engineering lead or developer integrating an LLM into a classification pipeline, a ticket router, or a data ingestion workflow where the output feeds directly into a database column with a CHECK constraint, an API enum, or a state machine transition.

Use this prompt when the cost of an invalid enum value is high—for example, when a bad status code would corrupt a reporting dashboard, stall an order fulfillment workflow, or require manual data repair. It is appropriate for high-volume, automated classification tasks where you can define the complete set of acceptable values upfront. This includes scenarios like triaging support tickets by priority (e.g., 'critical', 'high', 'medium', 'low'), setting order statuses from customer emails ('confirmed', 'shipped', 'delivered', 'cancelled'), or labeling content moderation flags ('safe', 'sensitive', 'violation'). The prompt is not suitable for open-ended analysis, creative generation, or cases where the set of possible outputs is unknown or unbounded. If you need the model to explain its reasoning, provide a confidence score, or handle truly ambiguous inputs with a clarification question, you should use a different prompt architecture or add those fields to the output schema explicitly.

Before using this prompt, you must have a complete, documented list of valid enum values and a clear definition for each one. Ambiguity in your own taxonomy will produce unreliable outputs. You should also have a set of representative test cases, including edge cases that are deliberately close to the boundary between two enum values. Do not use this prompt if your enum set changes frequently or if you cannot commit to maintaining the validation harness that enforces it. The next step is to copy the prompt template, populate the [VALID_ENUMS] and [INPUT] placeholders, and wire it into an application harness that validates the output before it touches any downstream system.

This template is designed to be copied directly into your prompt management system or application code. It forces the model to select a value exclusively from a predefined set for a critical field, such as status, category, or priority. The prompt uses a combination of explicit instruction, a constrained output schema, and a fallback mechanism to prevent out-of-vocabulary values that would break downstream automation. Before integrating, you must replace every square-bracket placeholder with the concrete values for your specific use case.

textCopy
You are a classification engine. Your only task is to analyze the provided input and output a single JSON object. You must strictly adhere to the output schema and constraints defined below.

## INPUT
[INPUT]

## OUTPUT SCHEMA
You must produce a JSON object with exactly these fields:
{
  "classification_id": "string (a unique identifier for this classification event)",
  "primary_status": "string (must be one of the allowed enum values)",
  "confidence_score": "number (between 0.0 and 1.0)",
  "rationale": "string (a brief, verbatim quote or direct reference from the input that justifies the primary_status)"
}

## CONSTRAINTS
- The `primary_status` field MUST be one of the following values: [ALLOWED_ENUMS]. Do not use synonyms, approximations, or any value not in this list.
- If the input is ambiguous or does not clearly map to a single allowed status, you MUST set `primary_status` to "[FALLBACK_ENUM]" and set `confidence_score` to a value below [CONFIDENCE_THRESHOLD].
- Do not invent new statuses. Do not combine statuses. Do not output the status in a different case.
- The `rationale` field must contain an exact, unaltered substring from the input that supports your decision.

## EXAMPLES
[EXAMPLES]

## RISK LEVEL
[RISK_LEVEL]

To adapt this template, start by defining the [ALLOWED_ENUMS] list, which is the single source of truth for your application's state machine. The [FALLBACK_ENUM] is your safety net; it should be a value your downstream system can process without error, such as UNKNOWN or PENDING_REVIEW. The [CONFIDENCE_THRESHOLD] is a critical tuning parameter that determines when the model should use the fallback. Populate [EXAMPLES] with at least two few-shot demonstrations: one showing a clear classification and another showing an ambiguous case that correctly falls back. For high-stakes workflows, set [RISK_LEVEL] to HIGH and ensure your implementation harness routes low-confidence or fallback outputs to a human review queue instead of proceeding automatically.

The enum control prompt is designed to be the final generation step before a status or category value enters your application database. It should sit behind a thin API endpoint or queue worker that receives unstructured text, enriches it with the predefined enum list and optional context, calls the model, and then validates the output before persisting it. Do not pass the raw model output directly to your state machine or database—always run it through a post-generation validation harness that checks for exact enum membership, correct JSON structure, and the presence of the required confidence and reasoning fields.

The validation harness should perform three checks in order. First, parse the JSON and confirm the status field is a string that exactly matches one of the allowed enum values using a case-sensitive comparison. Second, verify that confidence is a number between 0 and 1. Third, if you included an [UNKNOWN_FALLBACK] in the prompt, confirm that any input classified as that fallback value has a confidence below your defined threshold (typically 0.7). If validation fails, do not silently accept the output. Instead, implement a retry loop with a maximum of two additional attempts, appending the specific validation error to the next request so the model can self-correct. If all retries are exhausted, log the raw input, the failed outputs, and the validation errors to an observability system, then route the item to a human review queue with the model's best-effort classification attached as a suggestion.

For model choice, prefer models with strong instruction-following and JSON mode capabilities. If your provider supports structured outputs with a JSON Schema parameter (such as OpenAI's response_format with json_schema or equivalent), use it to enforce the output shape at the API level rather than relying solely on the prompt. This provides a second layer of defense against malformed JSON. When structured output mode is unavailable, increase the prompt's format instructions and add a post-generation JSON repair step using a library like json-repair before attempting validation. For high-throughput pipelines, consider caching the system prompt prefix and batching requests where latency allows. Always include the [ENUM_VALUES] as a JSON array in the prompt rather than a prose list—this reduces the chance the model invents a synonym or near-match.

Finally, instrument the entire pipeline with metrics: count of successful classifications, validation failures, retry attempts, fallback classifications, and human escalations. Set alerts on sudden increases in fallback or validation failure rates, which often indicate either a change in input distribution or model behavior drift. If your enum values change, treat the prompt update as a code change—version it, test against a golden dataset of known inputs, and run a shadow deployment before cutting over production traffic.