Acronym Normalization and Expansion Prompt

This prompt is designed for RAG operators and search engineers who manage retrieval over domain-heavy corpora—technical documentation, internal engineering wikis, clinical reports, or legal filings—where acronyms and abbreviations are the primary currency. The job-to-be-done is pre-retrieval query normalization: taking a user query that contains shorthand like 'CKD stage 3 tx options' and expanding it to 'chronic kidney disease stage 3 treatment options' before it hits a vector or keyword index. The ideal user is someone who already has a maintained acronym glossary and needs a repeatable, testable way to apply it at query time without manual rewriting. Required context includes the raw user query, a structured glossary mapping acronyms to their canonical expansions, and optionally a domain context string to help disambiguate terms that have multiple valid expansions.

Do not use this prompt when the acronym glossary is missing, stale, or untrusted. The model will expand what it knows from training data, which may not match your internal terminology, leading to silent mismatches that degrade retrieval precision. This prompt is also insufficient for queries where the acronym itself is the intended search term—for example, a user searching for 'AWS' meaning Amazon Web Services should not have it expanded unless your index uses the full form. In high-stakes domains like healthcare or aerospace, always route expansions flagged as ambiguous or low-confidence to a human reviewer before retrieval executes. The prompt is a normalization step, not a replacement for a proper entity resolution system or a live terminology service.

Before wiring this into production, you need a validation harness that checks every expansion against the provided glossary. The prompt includes a structured output schema that requires the model to cite the glossary entry used for each expansion. Your application layer should parse that output and reject any expansion where the source field is missing or doesn't match a known glossary key. This is the single most important failure mode to guard against: the model confidently expanding an acronym using its own parametric knowledge instead of your controlled vocabulary. Start with a small golden set of 50 queries that cover single-acronym, multi-acronym, ambiguous, and unknown-acronym cases, and measure both expansion accuracy and retrieval impact before scaling.

This prompt template is designed to be copied directly into your application or prompt management system. It accepts a user query containing domain-specific acronyms and abbreviations, a glossary of known terms, and a set of behavioral constraints. The model is instructed to expand every recognized acronym to its canonical full form, flag ambiguous expansions, and preserve the original query structure so the rewritten output can be passed directly to a retrieval engine. The template uses square-bracket placeholders for all variable inputs, making it safe to inject dynamic content without confusing the model's instruction boundary.

textCopy
You are an acronym normalization engine for a retrieval system. Your job is to expand every acronym and abbreviation in the user's query to its full canonical form using ONLY the provided glossary. Do not invent expansions. Do not expand terms that are already in their full form.

## GLOSSARY
[GLOSSARY]

## CONSTRAINTS
[CONSTRAINTS]

## INPUT QUERY
[INPUT]

## OUTPUT INSTRUCTIONS
Return a JSON object with the following schema:
{
  "original_query": "string (the exact input query)",
  "normalized_query": "string (the query with all recognized acronyms expanded)",
  "expansions": [
    {
      "acronym": "string",
      "expansion": "string",
      "confidence": "high|medium|low",
      "ambiguity_note": "string or null (explain if multiple expansions exist in glossary)"
    }
  ],
  "unrecognized_terms": ["string (acronyms not found in glossary)"],
  "ambiguous_terms": ["string (acronyms with multiple possible expansions)"]
}

## RULES
1. Match acronyms case-insensitively against the glossary.
2. If an acronym has multiple entries in the glossary, mark confidence as 'low', include all candidates in ambiguity_note, and select the most contextually probable expansion for normalized_query.
3. If an acronym is not in the glossary, add it to unrecognized_terms and leave it unexpanded in normalized_query.
4. Preserve all non-acronym text, punctuation, and query structure exactly.
5. Do not expand common abbreviations that are not in the glossary unless they are unambiguous domain terms.

To adapt this template, replace [GLOSSARY] with a structured list of acronym-to-expansion mappings. The glossary can be provided as a JSON object, a markdown table, or a simple ACRONYM: Expansion list. For high-throughput production systems, keep the glossary concise and limited to the domain's active terminology to reduce token consumption. Replace [CONSTRAINTS] with any additional rules specific to your domain, such as 'prefer clinical expansions over colloquial ones' or 'never expand API to anything other than Application Programming Interface.' The [INPUT] placeholder should receive the raw user query string. If your system already performs query cleaning, inject the cleaned query here. The output schema is designed to be machine-readable so your retrieval pipeline can log expansions, route ambiguous queries for human review, and skip retrieval when too many terms are unrecognized. Before deploying, run this prompt against a golden dataset of queries with known acronyms and verify that the normalized_query field produces the expected retrieval results.

The acronym normalization prompt should sit directly between the user's raw query and your retrieval engine. In a typical RAG pipeline, this means placing it as a pre-retrieval transformation step: user input enters the harness, the prompt expands and normalizes acronyms against your provided glossary, and the rewritten query is passed to your vector store, keyword index, or hybrid search. Do not send the raw user query to retrieval without this normalization step if your corpus uses acronyms heavily, as mismatched abbreviations are a leading cause of retrieval failure in technical domains.

The implementation harness requires three components: a glossary store, a validation layer, and a fallback path. The glossary store should be a version-controlled JSON or YAML file mapping acronyms to their canonical expansions, with a context field for disambiguation (e.g., "ML": [{"expansion": "Machine Learning", "context": "AI/software"}, {"expansion": "Maximum Likelihood", "context": "statistics"}]). The validation layer must check that every expansion returned by the model exists in your glossary; if the model produces an expansion not present in the glossary, flag it as a hallucination and either fall back to the original acronym or route to a human review queue. The fallback path handles ambiguous acronyms: when the model cannot disambiguate between multiple valid expansions, the harness should generate multiple query variants and execute parallel retrieval, then deduplicate and rank results. Log every normalization decision—original query, detected acronyms, chosen expansions, confidence scores, and any fallback triggers—so you can audit retrieval quality degradation over time.

For model choice, prefer a fast, low-cost model for this pre-retrieval step since latency adds up in user-facing RAG applications. A model like GPT-4o-mini, Claude Haiku, or a fine-tuned small open-weight model works well. Set a strict timeout (200-500ms) and implement a circuit breaker: if the normalization step fails or times out, pass the original query through to retrieval rather than blocking the user. Include a normalization_applied boolean in your retrieval metadata so downstream answer generation can adjust its confidence. Finally, build an eval harness that runs a golden set of acronym-heavy queries through the pipeline weekly, comparing retrieval recall with and without normalization to measure the prompt's ongoing value and detect glossary drift.