Domain-Specific Abbreviation Expansion Prompt

This prompt solves a specific retrieval problem: your users search for 'CKD mgmt' but your technical documentation only mentions 'Chronic Kidney Disease management.' When a vector or keyword index is built from precise, unabbreviated source material, user queries that rely on domain shorthand, acronyms, or initialisms will fail to retrieve the right documents. The job of this prompt is to act as a pre-retrieval translator, expanding every abbreviation in a user query to its canonical full form using a glossary you provide, so the rewritten query matches the language of your index.

The ideal user is a search engineer, RAG developer, or platform operator who already maintains a controlled abbreviation glossary for their domain—whether that is clinical terminology, engineering specs, financial instruments, or legal codes. You must supply that glossary as part of the prompt context. This prompt is not a general-purpose acronym expander. It will not guess expansions from the model's training data. If you do not provide a glossary, or if your glossary is incomplete, the prompt will return low-confidence or missing expansions, and you should treat those as signals to update your glossary, not as acceptable outputs. The prompt also distinguishes between ambiguous abbreviations by analyzing surrounding query context, so it works best when queries contain enough co-occurring terms to disambiguate.

Do not use this prompt when the user query is already well-formed for your index, when you lack a maintained glossary, or when the retrieval system can handle abbreviation variants natively through query-time synonym filters or embedding models fine-tuned on your domain. This prompt adds latency and token cost to every query. Reserve it for domains where abbreviation density is high and retrieval precision is measurably degraded without expansion. Before deploying, run a batch evaluation over historical queries to confirm that abbreviation expansion improves recall without introducing noise. If expansion causes over-retrieval, constrain the prompt to expand only high-confidence abbreviations and leave low-confidence terms untouched.

This prompt template is designed to be dropped into a RAG preprocessing pipeline that handles abbreviation-heavy technical queries. It takes a user query and a domain glossary as input, then outputs a rewritten query with all abbreviations expanded. The prompt is structured to require explicit reasoning for each expansion, distinguish between ambiguous abbreviations using surrounding context, and attach a confidence score to every decision. This traceability is critical for debugging retrieval failures and for audit workflows in regulated domains.

textCopy
You are an abbreviation expansion engine for a technical documentation retrieval system. Your job is to rewrite user queries by expanding domain-specific abbreviations to their full forms using ONLY the provided glossary. You must not invent expansions.

## INPUT
User Query: [USER_QUERY]
Domain Glossary (JSON): [GLOSSARY_JSON]

## GLOSSARY FORMAT
The glossary is a JSON object where each key is an abbreviation (case-sensitive) and the value is an array of possible expansions. Each expansion is an object with "full_form" and "context_hints" (an array of keywords that suggest this expansion is correct).

Example:
{
  "PCA": [
    {"full_form": "Principal Component Analysis", "context_hints": ["dimensionality", "variance", "eigenvalue"]},
    {"full_form": "Patient Controlled Analgesia", "context_hints": ["pain", "morphine", "postoperative"]}
  ]
}

## INSTRUCTIONS
1. Identify every abbreviation in the user query that appears as a key in the glossary.
2. For each abbreviation, select the correct expansion by matching context words in the query against the "context_hints" for each candidate.
3. If no context words match, select the most common expansion and flag it as low confidence.
4. If an abbreviation is not in the glossary, leave it unexpanded and flag it as "unknown".
5. Do not expand words that are not in the glossary, even if they look like abbreviations.
6. Preserve all original query words that are not abbreviations.

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "expanded_query": "string",
  "expansions": [
    {
      "abbreviation": "string",
      "selected_expansion": "string",
      "confidence": "high|medium|low",
      "matched_context_words": ["string"],
      "alternative_candidates": ["string"]
    }
  ],
  "unknown_abbreviations": ["string"]
}

## CONSTRAINTS
- Do not hallucinate expansions. If an abbreviation is not in the glossary, list it under "unknown_abbreviations".
- If multiple glossary entries match with equal context evidence, select the first one and set confidence to "low".
- The "expanded_query" must be a complete, readable sentence with expansions substituted inline.
- Do not add, remove, or reorder words except for abbreviation expansion.

To adapt this template, replace [USER_QUERY] with the raw query string and [GLOSSARY_JSON] with your domain glossary serialized as JSON. The glossary must be pre-built and validated before this prompt runs; do not rely on the model to infer expansions from general knowledge. For high-stakes domains like healthcare or finance, add a [RISK_LEVEL] parameter that gates whether low-confidence expansions are applied or flagged for human review. The output schema is designed to be machine-readable so your application can log the expansion trace, surface low-confidence decisions to an operator, and feed the expanded query directly into your retrieval step.

This prompt is designed to sit directly before your retrieval step in a RAG pipeline. It takes a raw user query and a provided abbreviation glossary, then outputs an expanded query string plus a structured trace of every expansion decision. The harness must enforce that the model only expands abbreviations present in the glossary and must not invent expansions for unknown terms. Wire this as a synchronous pre-processing step: user query → abbreviation expansion → expanded query → retrieval engine. The prompt expects a glossary provided at runtime, not baked into the system prompt, so your harness must inject the glossary as part of the [CONTEXT] block on every call.

For production implementation, wrap the LLM call in a validation layer that parses the JSON output and cross-references each abbreviation field against the input glossary. If the model returns an abbreviation not present in the provided glossary, flag it as a hallucination and either strip that expansion or route the query to a human review queue depending on your [RISK_LEVEL] configuration. Implement a retry loop with a maximum of two attempts: if the output fails JSON parsing or schema validation, re-invoke with the error message appended to the prompt. Log every expansion decision—including confidence scores, context clues used, and whether the expansion was unambiguous or required disambiguation—so your observability stack can surface patterns like frequently ambiguous abbreviations that need glossary refinement.

Model choice matters here. This task requires precise instruction-following and low hallucination rates on structured extraction, not creative generation. Prefer models with strong JSON mode support and low latency, since this step adds overhead before retrieval. If your glossary exceeds ~500 entries, split it: pass only the top-N candidate abbreviations based on a fast string match against the query, rather than the entire glossary. For high-compliance domains, add a human-in-the-loop gate: when the model flags an abbreviation as ambiguous: true or confidence falls below your threshold, queue the expansion for review before retrieval proceeds. The next step after this harness is to pass the expanded_query string to your retrieval engine and store the expansion_trace in your query log for debugging relevance failures.