Case Normalization Prompt for Text Fields

This prompt is for data engineers and ETL developers who need to enforce consistent casing rules across text fields before ingestion into a target system. The primary job-to-be-done is transforming a raw, unformatted string into a predictable, schema-aligned format—applying title case to person names, upper case to product codes, or lower case to email addresses—without destroying meaningful information like acronyms or hyphenated names. The ideal user is building a data pipeline, cleaning a CRM, or preparing a dataset for analytics and needs a repeatable, auditable normalization step that can be configured per field.

Use this prompt when you have a defined target casing rule for a specific field and a known list of exceptions (e.g., 'McDonald', 'iPhone', 'USA'). It is designed for single-field transformations where the input is a plain text string and the output must be a single normalized string. The prompt handles acronym preservation, locale-aware title casing for names, and configurable override lists. It is not a general-purpose text formatter, a grammar checker, or a tool for normalizing entire documents. Do not use this prompt for fields where casing carries semantic meaning that cannot be captured by a static exception list, or for free-text fields where multiple casing styles coexist intentionally.

Before wiring this into a production pipeline, define your exception lists and casing rules per field in a configuration layer outside the prompt. The prompt template accepts these as parameters, so the same template can be reused for 'last_name' with title case and 'sku_code' with upper case. Always validate the output against expected patterns—for example, a normalized email address must still match a basic email regex. For high-volume pipelines, log the original value, the applied rule, and the normalized output to create an audit trail. If a field's casing rule is ambiguous or the input contains mixed signals, route it to a manual review queue instead of silently applying a transformation.

This prompt template provides a production-ready instruction set for normalizing the casing of text fields. It accepts a raw input string along with a target casing rule, an optional exception list, and locale-specific flags. The template is designed to be copied directly into your prompt management system or codebase, with square-bracket placeholders that you replace with actual values at runtime.

textCopy
You are a precise text normalization engine. Your task is to apply consistent casing rules to the provided input string.

INPUT: [INPUT_STRING]

TARGET_CASING: [TARGET_CASING]
# Valid values: 'title', 'upper', 'lower', 'sentence', 'preserve'

EXCEPTION_LIST: [EXCEPTION_LIST]
# A JSON array of strings that must retain their exact casing, e.g., ["iPhone", "macOS", "USA"]

LOCALE: [LOCALE]
# An IETF BCP 47 language tag, e.g., 'en-US', 'fr-FR', 'de-DE'

ACRONYM_HANDLING: [ACRONYM_HANDLING]
# Valid values: 'preserve' (keep known acronyms uppercase), 'force' (apply target casing to all)

HYPHENATED_NAME_RULE: [HYPHENATED_NAME_RULE]
# Valid values: 'capitalize-both' (e.g., Smith-Jones), 'capitalize-first' (e.g., Smith-jones)

OUTPUT_SCHEMA:
{
  "normalized_text": "string",
  "applied_rule": "string",
  "changes_made": [
    {
      "original": "string",
      "normalized": "string",
      "reason": "string"
    }
  ],
  "exceptions_applied": ["string"],
  "warnings": ["string"]
}

CONSTRAINTS:
- Return ONLY valid JSON matching the output schema.
- Do not modify any string present in the EXCEPTION_LIST.
- For 'title' casing, follow the locale's title casing conventions (e.g., en-US capitalizes nouns, verbs, adjectives, adverbs; does not capitalize articles, coordinating conjunctions, or short prepositions unless they are the first or last word).
- For hyphenated names, apply the HYPHENATED_NAME_RULE.
- If ACRONYM_HANDLING is 'preserve', detect known acronyms (all-uppercase words of 2+ characters) and keep them uppercase regardless of TARGET_CASING.
- Flag any ambiguous input in the warnings array (e.g., input already in mixed case with no clear pattern).
- If TARGET_CASING is 'preserve', return the input unchanged and note it in warnings.

To adapt this template, replace each square-bracket placeholder with the appropriate value for your use case. The TARGET_CASING field accepts five modes: title for proper name and heading casing, upper for codes and identifiers, lower for emails and domains, sentence for prose fields, and preserve for fields that should not be modified. The EXCEPTION_LIST is critical for brand names, product codes, and technical terms that must retain their exact casing. When integrating this prompt into a data pipeline, always validate the output JSON against the schema before ingesting the normalized text into downstream systems. For high-risk fields such as legal names or regulatory identifiers, route low-confidence results or warnings to a human review queue before final commit.

The case normalization prompt is designed to be called as a deterministic transformation step within a broader ETL or data ingestion pipeline. It should be treated as a stateless function: accept a raw string and a set of casing rules, return a normalized string with metadata. Wire it as a pre-ingestion processor that runs after extraction but before database insertion. The prompt expects a JSON payload containing the input string, target case type, an exception list, and any locale or acronym preservation flags. The model returns a structured JSON response with the normalized string, a confidence score, and a list of applied overrides.

For production implementation, wrap the LLM call in a thin service layer that handles validation, retries, and logging. Before calling the model, validate that the input string is not null and that the target case is one of the supported enum values: title, upper, lower, sentence, or preserve. After receiving the response, validate the output schema: confirm the normalized_text field is a non-empty string, the confidence field is a float between 0.0 and 1.0, and the applied_overrides array contains only strings from the submitted exception list. If validation fails, retry once with a more explicit error message injected into the prompt context. If the retry also fails, route the record to a dead-letter queue for human review rather than silently ingesting bad data.

Model choice matters here. For high-throughput pipelines processing millions of records, use a fast, cost-optimized model like GPT-4o-mini, Claude Haiku, or a fine-tuned open-weight model. The task is pattern-matching heavy and does not require deep reasoning. Set temperature=0 to maximize deterministic output. For regulated environments where every casing decision must be auditable, log the full prompt, response, and validation result to an append-only audit store. Attach the applied_overrides list and confidence score as metadata columns alongside the normalized value in your target database. This gives downstream consumers visibility into which transformations were applied and how confident the system was in each decision. Avoid using this prompt for fields where casing carries legal significance—such as proper names in contracts—without mandatory human review of all low-confidence outputs.