Dialogue State to Query Rewrite Prompt Template

This prompt is for agent builders and conversational AI engineers who maintain a structured dialogue state during a session and need to convert that state into a retrieval query. Unlike simple anaphora resolution or decontextualization prompts that operate on raw conversation history, this prompt assumes you already have a machine-readable dialogue state containing confirmed slots, user goals, open questions, and constraint flags. The prompt translates that structured state into a single, self-contained query string optimized for vector, keyword, or hybrid retrieval backends. Use this when your dialogue manager tracks slots explicitly and you need retrieval to reflect what the system has confirmed, not just what the user last said.

The ideal user has a dialogue state object with fields like intent, confirmed_slots, open_questions, constraints, and user_goal. This prompt is not a substitute for building that state tracker. If you only have raw conversation history, use a decontextualization or anaphora resolution prompt instead. This prompt adds value when the dialogue manager has already resolved ambiguities and confirmed critical details with the user—retrieval should honor those confirmed facts rather than re-deriving them from the latest utterance. The prompt also helps when the retrieval backend expects a single dense query but the dialogue state contains multiple active constraints that must be fused into one coherent string.

Do not use this prompt when the dialogue state is empty, unconfirmed, or stale. If the system has not yet confirmed a slot, including it in the query rewrite can poison retrieval with incorrect assumptions. Similarly, if the user has just contradicted a previously confirmed slot, the dialogue state must be updated before this prompt runs. A common failure mode is treating every slot as equally relevant to the current retrieval need—the prompt must be instructed to prioritize slots that align with the active user goal and deprioritize background context. Before wiring this into production, add a validation step that checks whether the generated query contradicts any confirmed slot in the input state, and log mismatches for review.

This template transforms a structured dialogue state object into a standalone retrieval query. It resolves confirmed slots, user goals, and open questions into a single search string that reflects everything the system knows so far. The prompt expects a JSON dialogue state as input and produces a query rewrite plus a confidence score and a list of unresolved slots that may require clarification before retrieval.

textCopy
You are a dialogue-state-to-query rewriter for a retrieval system. Your job is to convert the current dialogue state into a single, self-contained search query that captures the user's confirmed intent, filled slots, and any open questions that need evidence.

INPUT DIALOGUE STATE:
[DOCUMENT]

INSTRUCTIONS:
1. Review the confirmed slots, user goal, and open questions in the dialogue state.
2. Produce a rewritten query that:
   - Incorporates all confirmed slot values as explicit search terms.
   - Reflects the user's stated goal.
   - Includes terms for open questions that can be resolved through retrieval.
   - Is self-contained and does not rely on prior conversation context.
   - Uses the domain terminology provided in [TERMINOLOGY_MAP] when available.
3. If the dialogue state is missing critical slots required for a meaningful query, set confidence to LOW and list those slots in unresolved_slots.
4. If the dialogue state contains contradictory slot values, flag the conflict in the notes field and use the most recently confirmed value.

OUTPUT SCHEMA:
{
  "rewritten_query": "string",
  "confidence": "HIGH | MEDIUM | LOW",
  "unresolved_slots": ["slot_name"],
  "notes": "string"
}

CONSTRAINTS:
- Do not invent slot values not present in the dialogue state.
- Do not resolve open questions by guessing; only include them as search terms.
- If the dialogue state is empty or contains only a greeting, return an empty query and set confidence to LOW.
- Preserve any [NEGATION_SIGNALS] from the dialogue state in the rewritten query.

[EXAMPLES]

Wire the [DOCUMENT] placeholder with your serialized dialogue state JSON. Populate [TERMINOLOGY_MAP] with domain-specific term mappings when users may use different language than your knowledge base. Supply [NEGATION_SIGNALS] as a list of terms or phrases that indicate the user has rejected a slot value. The [EXAMPLES] block should contain at least two few-shot examples showing a dialogue state and its correct rewritten query, including one example with unresolved slots and one with a full state. Before sending this prompt to production, validate that the output conforms to the schema using a JSON validator in your harness. For high-risk domains, route LOW-confidence outputs to a human reviewer or a clarification prompt before retrieval executes.

This prompt is designed to sit between your dialogue state tracker and your retrieval system. The application harness should call this prompt only when the dialogue state has been updated with new user input and confirmed slots. Do not call it on every turn if the state is unchanged; instead, cache the last rewrite and invalidate it when slots, goals, or open questions are modified. The harness must serialize the dialogue state into a structured object matching the [DIALOGUE_STATE] placeholder, typically a JSON blob containing confirmed_slots, user_goal, open_questions, and conversation_history_summary. Avoid passing raw transcript logs directly—pre-summarize turns into a compact state representation to keep token usage predictable and latency low.

Validation is the most critical part of the harness. After receiving the rewritten query, validate it against the input dialogue state: every confirmed slot should be reflected in the query's constraints, and no hallucinated constraints should appear that weren't in the state. Implement a state-query consistency check that diffs the confirmed slots against the query's filter clauses. If the check fails, log the mismatch with the dialogue state version, the generated query, and the specific slots that were dropped or invented. Then retry with a stricter [CONSTRAINTS] block that explicitly lists the slots that must appear. Set a maximum of 2 retries before falling back to a simpler query constructed programmatically from the confirmed slots alone. For high-stakes domains like healthcare or finance, route consistency failures to a human review queue rather than silently serving a degraded query.

Model choice matters here. Use a model with strong instruction-following and JSON manipulation capabilities (GPT-4o, Claude 3.5 Sonnet, or equivalent). Set temperature to 0 or a very low value (0.1) to minimize creative drift in constraint translation. The harness should log every rewrite attempt with: the dialogue state version hash, the generated query, the consistency check result, the retry count, and the final query served to retrieval. This audit trail is essential for debugging retrieval failures—when a user says 'it didn't find what I asked for,' you need to trace whether the rewrite dropped a constraint, the retrieval index missed it, or the answer generator ignored it. Wire these logs into your existing observability stack (e.g., Datadog, Grafana, or custom trace storage) with the dialogue state version as the primary correlation key.