Enum Value Mapping and Standardization Prompt Template

This prompt is for integration engineers and data pipeline developers who need to map inconsistent, free-text model outputs to a strict, controlled vocabulary. The core job-to-be-done is resolving synonyms, case variations, and near-matches into a single canonical enum value that downstream systems—like databases, API validators, or state machines—can consume without error. You should use this prompt when the model's semantic intent is correct but its surface form is unreliable, such as when a classification label appears as 'high', 'HIGH', 'High Priority', or 'critical' but must be stored as SEVERITY_CRITICAL.

The ideal user has a predefined target schema, such as a JSON Schema enum constraint or a database CHECK constraint, and a set of known valid values. They provide this target vocabulary, along with the raw model output, as input to the prompt. The prompt is designed to handle exact matches, case-insensitive mapping, synonym resolution (e.g., 'car' to VEHICLE), and fuzzy matching with a confidence score. It also produces an explicit audit trail for any input that cannot be mapped, flagging it for human review or a fallback queue. This is not a prompt for designing the vocabulary itself; it assumes the canonical values are already defined and stable.

Do not use this prompt when the model's output is already reliably structured, such as when you control the generation step with a strict JSON schema and the model consistently populates an enum field. In that case, schema validation in the application layer is faster and cheaper. Also avoid this prompt for open-ended classification where the set of valid values is unknown or evolving; this is a standardization tool, not a taxonomy builder. For high-stakes domains like healthcare or finance, always route unmapped or low-confidence outputs to a human review queue and log the full prompt response for auditability.

This template is the core instruction set for an Enum Value Mapping and Standardization system. It accepts a list of free-text input values and a target controlled vocabulary, then returns each input mapped to its best canonical match. The prompt is designed to be wrapped in application code that supplies the dynamic [INPUT_VALUES], [TARGET_ENUM], and [CONSTRAINTS] at runtime. It handles synonym resolution, case-insensitive matching, fuzzy matching with explicit confidence scores, and multi-language normalization. For high-risk domains, the prompt includes an unmapped-value escalation path that requires human review before a default is applied.

textCopy
You are an enum value standardization engine. Your job is to map each input value to exactly one canonical value from the provided target enum. You must not invent new enum values.

## INPUT VALUES
[INPUT_VALUES]

## TARGET ENUM (CANONICAL VALUES ONLY)
[TARGET_ENUM]

## CONSTRAINTS
[CONSTRAINTS]

## MAPPING RULES
1. For each input value, find the best matching canonical value from the target enum.
2. Match priority: exact match > case-insensitive match > synonym match > fuzzy match.
3. If multiple canonical values are plausible, choose the one with the highest confidence and note the alternatives.
4. If no canonical value meets the minimum confidence threshold, mark the input as UNMAPPED and provide the reason.
5. Do not map an input to a canonical value if the confidence is below the threshold specified in constraints.

## OUTPUT SCHEMA
Return a JSON object with this exact structure:
{
  "mappings": [
    {
      "input_value": "string (original input)",
      "canonical_value": "string | null (matched canonical value, or null if unmapped)",
      "confidence": number (0.0 to 1.0),
      "match_type": "exact | case_insensitive | synonym | fuzzy | unmapped",
      "alternatives": ["string (other plausible canonical values, empty if none)"],
      "unmapped_reason": "string | null (explanation if unmapped, null otherwise)"
    }
  ],
  "unmapped_count": number,
  "total_inputs": number
}

## EXAMPLES
[EXAMPLES]

## IMPORTANT
- Preserve the original input value exactly in the output.
- If the input is empty or whitespace-only, mark it as UNMAPPED with reason "empty_input".
- If the target enum is empty, mark all inputs as UNMAPPED with reason "no_target_enum_provided".
- Do not include commentary outside the JSON output.

To adapt this template, replace the square-bracket placeholders with your application's runtime data. [INPUT_VALUES] should be a JSON array of strings or a newline-separated list. [TARGET_ENUM] should be a JSON array of canonical string values. [CONSTRAINTS] should specify the minimum confidence threshold (e.g., 0.7), any domain-specific synonym mappings, and the policy for unmapped values (e.g., escalate_for_review or map_to_default). [EXAMPLES] should include 3-5 few-shot demonstrations covering exact matches, fuzzy matches, and unmapped edge cases. For production use, always validate the output JSON against the schema before ingesting the mappings into downstream systems. If the unmapped count exceeds a configured threshold, route the entire batch for human review rather than silently applying defaults.

The Enum Value Mapping and Standardization prompt is designed to sit inside a post-generation repair loop, not as a standalone user-facing endpoint. After a primary model generates a response containing a field that must conform to a controlled vocabulary, your application should extract that field, validate it against the canonical enum, and only invoke this prompt when the value fails validation. This keeps latency and cost low for the happy path while providing a reliable recovery mechanism for the 5–15% of cases where models produce synonyms, case variants, or near-matches instead of canonical values.

Wire the prompt into a validation-retry pipeline with a strict contract. The application must supply three inputs: the raw model output value ([RAW_VALUE]), the canonical enum definition as a JSON array of valid strings ([VALID_ENUM]), and an optional context snippet from the original request ([CONTEXT]) to aid disambiguation. The prompt returns a JSON object with canonical_value, confidence (0.0–1.0), match_type (exact, synonym, fuzzy, or unmapped), and audit_note. Your harness should parse this response and check confidence against a configurable threshold—typically 0.85 for automated acceptance, with values below that routed to a human review queue or logged for offline analysis. Never silently accept an unmapped result; always escalate it.

For model choice, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is sufficient for this task because the prompt operates on a single value with a constrained output schema. Set temperature=0 to eliminate variance in canonicalization decisions. Implement retry logic with a maximum of two attempts: if the prompt returns malformed JSON or a confidence below threshold, retry once with the same inputs. If the second attempt also fails, fall back to a configurable default value (if the field is optional) or escalate to a human operator (if the field is required). Log every invocation—raw input, canonical output, confidence, match type, and whether the result was auto-accepted or escalated—to build an audit trail that product and compliance teams can review. This log also serves as a dataset for periodically tuning the canonical enum list when patterns of unmapped values emerge.