Ellipsis Expansion Prompt for Incomplete Utterances

This prompt is designed for natural-language interface developers who need to resolve fragmentary user follow-ups—such as 'and the red one?' or 'what about Tuesday?'—into fully self-contained utterances. The core job-to-be-done is preprocessing: recovering omitted syntactic elements from the immediately preceding dialogue turn so that downstream intent classification and entity extraction operate on a complete sentence. The ideal user is an AI engineer or product developer building a multi-turn chat or voice assistant who has access to the prior turn's text and wants to avoid forcing users to repeat full context. This is a preprocessing step, not a dialogue management replacement.

Use this prompt when you have a clear, single prior turn available and the user's fragment is a direct syntactic continuation of that turn. Required inputs include the current fragmentary user message and the immediately preceding assistant or user turn. The output should be a single expanded utterance that preserves the original intent and entities without introducing new information. Do not use this prompt when the prior turn is unavailable, when the fragment introduces a completely new topic with no recoverable antecedent, or when the user is correcting a previous statement rather than continuing it. It is also not a substitute for a full dialogue state tracker or coreference resolution system that must handle long-range dependencies across many turns.

Before integrating this prompt into your pipeline, validate that your upstream context provider reliably surfaces the correct prior turn. A common failure mode is feeding the wrong turn—such as a system message or a much earlier user message—which causes the expansion to hallucinate a non-existent antecedent. Implement a guard that checks whether the expanded utterance contains entities or intents not present in the original fragment or prior turn. If your application operates in a high-stakes domain like healthcare or finance, route any expansion that introduces new entities to a human review queue. The next step after reading this playbook is to copy the prompt template, wire it into your preprocessing layer, and run the provided eval cases to establish a baseline accuracy before production deployment.

The prompt template below is designed to be inserted into your dialogue manager's model call whenever the user's current turn is classified as a fragment—an incomplete utterance that relies on syntactic or semantic material from prior turns to be understood. It takes the fragment, the recent dialogue history, and an optional set of known entities, and produces a single, self-contained expanded utterance. The template uses square-bracket placeholders that your application must populate with live session data before each inference call. Do not leave any placeholder unresolved when sending the request to the model.

textCopy
You are an utterance expansion module in a multi-turn dialogue system. Your job is to convert an incomplete user utterance into a fully specified, self-contained sentence by recovering omitted syntactic elements from the prior conversation history.

[CONSTRAINTS]
- Do not add new information, entities, or intent that is not present in the history or the current fragment.
- Preserve the user's original wording as much as possible; only insert the missing material.
- If the fragment cannot be resolved with high confidence from the history, output exactly: <UNRESOLVABLE>
- Do not answer the user's question or continue the conversation. Only output the expanded utterance.
- If the fragment is already a complete, self-contained utterance, output it unchanged.

[CONTEXT]
The following is the recent dialogue history, with turns labeled by speaker:
[HISTORY]

[INPUT]
Current user fragment: [FRAGMENT]

[OUTPUT_SCHEMA]
Return a JSON object with the following fields:
{
  "expanded_utterance": "The fully expanded, self-contained user utterance.",
  "resolution_confidence": "high|medium|low",
  "resolved_references": [
    {
      "original_fragment_text": "the red one",
      "resolved_entity": "the red Meridian backpack",
      "source_turn": 3
    }
  ]
}

If unresolvable, return:
{
  "expanded_utterance": "<UNRESOLVABLE>",
  "resolution_confidence": "low",
  "resolved_references": []
}

To adapt this template for your application, start by defining what constitutes a fragment in your system. You may use a lightweight classifier prompt or a simple heuristic—such as checking for sentence-ending punctuation or a minimum token count—to decide whether to route the user's turn through this expansion prompt before it reaches your main assistant logic. The [HISTORY] placeholder should be populated with the last N turns formatted consistently, typically as User: ... and Assistant: ... pairs. If your application maintains a structured entity set or a knowledge base, inject it into the [CONTEXT] block as additional grounding material. The [CONSTRAINTS] section is critical for preventing the model from hallucinating details or answering the question prematurely; adjust these rules if your domain requires the model to infer missing attributes like color or size from product catalogs rather than only from dialogue history. For high-stakes domains such as healthcare or finance, add a constraint requiring the model to set resolution_confidence to low and output <UNRESOLVABLE> whenever the fragment could map to multiple entities with materially different consequences, and route those cases to a human reviewer before the expanded utterance is used downstream.

The ellipsis expansion prompt is not a standalone feature; it is a preprocessing step that sits between the user's raw input and the downstream NLU, RAG retrieval, or agent planning system. In a production chat pipeline, every user turn should pass through this expansion step before any other processing. The prompt takes the current fragmentary utterance, the last N turns of dialogue history, and the active entity set as input, and it produces a fully expanded, self-contained utterance. This expanded utterance then replaces the original fragment in all downstream processing, ensuring that the assistant, retriever, or agent sees a complete, unambiguous request.

Wire the prompt as a synchronous preprocessing call before your main assistant invocation. The input payload should include: [CURRENT_UTTERANCE] (the raw user text), [DIALOGUE_HISTORY] (the last 3-5 turns as structured JSON with speaker, text, and turn ID), and [ACTIVE_ENTITIES] (a JSON array of entities mentioned in the session with their IDs, types, and attributes). The output should be validated against a strict schema: {"expanded_utterance": "string", "resolved_references": [{"original": "string", "resolved": "string", "entity_id": "string"}], "is_self_contained": boolean, "confidence": 0.0-1.0}. If is_self_contained is false or confidence is below your threshold (start with 0.85), route to a clarification prompt instead of proceeding with the expanded utterance. Log every expansion with the original fragment, the expanded result, and the confidence score for debugging and eval.

For model choice, use a fast, low-latency model for this preprocessing step—GPT-4o-mini, Claude Haiku, or a fine-tuned small model if you have training data. This prompt runs on every user turn, so latency and cost matter. Implement a retry with exponential backoff (max 2 retries) if the output fails schema validation. If the model hallucinates entities not present in [ACTIVE_ENTITIES], the validator must catch this by checking that all entity_id values in resolved_references exist in the input entity set. For high-stakes domains like healthcare or finance, add a human review queue for expansions where confidence is between 0.7 and 0.85, and hard-reject anything below 0.7 with a clarification request to the user. Never silently guess.

The most common production failure mode is stale entity sets. If your entity tracking system fails to update after a user correction or topic shift, the expansion prompt will resolve references against outdated entities. Mitigate this by running a staleness check on [ACTIVE_ENTITIES] before expansion: if any entity's last_mentioned_turn is more than 5 turns old, drop it from the input set or flag it as potentially stale. A second failure mode is over-expansion, where the model adds assumptions not present in the original fragment. Your eval harness should include a regression test that compares the expanded utterance against the original and flags any added content that cannot be directly traced to a reference resolution. Run this eval on a golden dataset of 50+ fragment-history pairs before every prompt update.