Enum and Constrained Vocabulary Adherence Prompt

This prompt is for product and platform teams whose downstream systems—databases, APIs, state machines, analytics pipelines—will break if they receive an unapproved category label, status code, or type value. The job-to-be-done is automated, field-level enforcement of a controlled vocabulary. The ideal user is an engineering lead or developer integrating an LLM into a product surface where a free-text field is not acceptable and a drop-down list already exists in the application layer. You need this prompt when the cost of an out-of-set value is a runtime exception, a rejected database write, or a corrupted reporting metric, not just a minor formatting annoyance.

Use this prompt when you have a defined set of allowed values per field—such as ['active', 'inactive', 'suspended'] for a status field or ['critical', 'high', 'medium', 'low'] for severity—and you need the model to audit its own output or the output of another model against that set. It works best as a post-generation validation step or as a constraint injected into a second-pass repair prompt. Do not use this prompt as your primary schema enforcement mechanism if you are using strict structured output modes (like GPT-4's response_format with a JSON Schema) that already enforce enum constraints at the token level; in those cases, use this prompt for offline evaluation and regression testing, not for runtime gating. Also avoid this prompt when the vocabulary is too large to fit in a prompt (e.g., thousands of product SKUs) or when fuzzy semantic matching is acceptable—this prompt enforces exact string matching against a closed set.

Before wiring this into a production pipeline, pair it with a validation harness that can parse the violation report and decide whether to retry, repair, or escalate. For high-stakes fields like payment statuses or clinical codes, always route violations to a human review queue rather than auto-correcting. The next section provides the copy-ready prompt template you can adapt with your own enum definitions and field mappings.

This prompt template is designed to be dropped into an evaluation harness that checks structured outputs for enum and constrained vocabulary adherence. It instructs the model to act as a schema-aware auditor, comparing field values against a provided list of allowed terms. The output is a machine-readable violation report, not a conversational reply. Use this when your product relies on downstream systems that break on unexpected category labels, status codes, or type values.

textCopy
You are an output auditor. Your task is to check a structured [OUTPUT] against a controlled vocabulary specification.

# INPUTS
- OUTPUT: The structured data to audit, provided as [OUTPUT].
- VOCABULARY: A mapping of field paths to their allowed values, provided as [VOCABULARY].
- CONSTRAINTS: Additional rules, such as case sensitivity, provided as [CONSTRAINTS].

# TASK
For every field path listed in [VOCABULARY], check the corresponding value in [OUTPUT]. If the value is not in the allowed set, record a violation.

# VIOLATION REPORT SCHEMA
Return a JSON object with the following structure:
{
  "pass": boolean,
  "violations": [
    {
      "field_path": string,
      "provided_value": string,
      "allowed_values": [string],
      "suggested_fix": string or null
    }
  ]
}

# RULES
- If a field is missing or null, treat it as a violation unless [CONSTRAINTS] explicitly allows it.
- For each violation, suggest the closest valid value from the allowed set in "suggested_fix". If no close match exists, set to null.
- Perform case-sensitive comparison unless [CONSTRAINTS] specifies case-insensitive matching.
- Do not add commentary outside the JSON object.

To adapt this template, replace the [OUTPUT], [VOCABULARY], and [CONSTRAINTS] placeholders with your actual data. The [VOCABULARY] input should be a JSON object mapping dot-notation field paths to arrays of strings, such as {"order.status": ["pending", "shipped", "delivered"], "order.priority": ["low", "medium", "high"]}. The [CONSTRAINTS] input can specify case sensitivity, null handling, or whether partial matches are acceptable. Before shipping, run this prompt against a test suite of deliberately perturbed enum values—such as misspellings, wrong case, and out-of-set labels—to verify that violations are caught and suggested fixes are reasonable. For high-stakes workflows where an incorrect enum could trigger a billing error or a compliance violation, route violation reports to a human review queue before automated repair.

This prompt is designed to operate as a post-generation validation gate, not as a real-time correction mechanism. The most effective implementation pattern is to place it immediately after your primary LLM call and before any downstream data ingestion. The prompt expects a structured input containing the original output and the allowed vocabulary set, and it returns a structured violation report. This report should be treated as a machine-readable signal: a zero-length violations array means the output is clean and can proceed automatically. Any non-empty violations array should trigger a defined recovery or escalation path, never a silent pass.

To wire this into an application, construct the prompt input programmatically. The [OUTPUT_TO_CHECK] should be the raw, unescaped string from your primary model. The [ALLOWED_VOCABULARY] should be a serialized JSON object mapping field paths to their allowed value arrays, generated from your source-of-truth schema registry. The [FIELD_PATHS_TO_CHECK] array tells the judge exactly which fields to inspect, preventing it from flagging free-text fields that are not constrained. After receiving the judge's response, parse the JSON and check violations.length. If zero, forward the original output. If greater than zero, log the full violation report for observability and decide on a recovery strategy. Common strategies include: retrying the primary model call with the violation report injected as a correction instruction, falling back to a more deterministic model, or routing the record to a human review queue if the field is business-critical.

For high-stakes applications like payment status codes or medical category labels, do not rely solely on the judge's suggested correction. The closest_valid_value field in the violation report is a heuristic based on string similarity and may not reflect business logic. Implement a secondary validation layer that maps the suggested correction against a canonical alias map or business rule engine before accepting it. Always log the full violation payload—including the original value, the field path, and the suggested correction—to your observability platform. This data is critical for detecting upstream prompt drift, model behavior changes, or gaps in your allowed vocabulary definitions. When deploying, start with a shadow mode that logs violations without blocking the pipeline, then graduate to active enforcement once you've tuned the allowed vocabularies and confirmed an acceptable false-positive rate against a golden test set of known valid and invalid outputs.