Dialogue Slot Extraction Prompt Template

This prompt is designed for AI engineers and product developers building copilots, form-filling assistants, or any multi-turn conversational interface that must gather structured data from a user over several exchanges. The core job-to-be-done is to convert a messy, natural-language conversation history into a clean, structured JSON object that represents the state of a target schema. You use this when your application needs to know not just what a user said, but what information has been reliably captured, what is still ambiguous, and what is completely missing—all without losing track of the conversation's context.

The ideal user is a developer integrating a Large Language Model into a product backend where the output must be machine-readable and deterministic enough to drive business logic, such as pre-filling a CRM record, populating an insurance claim, or configuring a software deployment. This prompt is appropriate when the target data shape is known in advance and can be described as a set of typed slots with clear definitions. It is not a general-purpose chat summarizer. You should not use this prompt when the conversation is purely open-ended, when the required data structure is unknown or evolving in real-time, or when the primary goal is to generate a fluent prose summary rather than a strict JSON object.

Before implementing, you must define a precise [OUTPUT_SCHEMA] with field names, types, descriptions, and constraints. The prompt's value is in its ability to track the confirmation status of each slot—labeling them as confirmed, ambiguous, or missing—which allows your application logic to decide whether to proceed, ask a clarifying question, or flag a record for human review. Do not use this prompt for single-turn extraction; a simpler schema-first prompt is more efficient for that. The primary production risk is hallucinated slot values, so the accompanying harness must validate that every confirmed value is explicitly grounded in a user utterance from the provided [CONVERSATION_HISTORY].

Next, review the copy-ready prompt template in the following section. You will need to adapt the [OUTPUT_SCHEMA], [CONVERSATION_HISTORY], and [CLARIFICATION_RULES] placeholders to your specific use case before wiring it into your application.

This prompt template is designed to be wired into a copilot or form-filling assistant's state management pipeline. It takes the full conversation history and a target slot schema as input, then produces a structured JSON object that captures which slots have been filled, which values are ambiguous, and which slots remain missing. The template uses square-bracket placeholders so you can swap in your own schema, conversation data, and constraints without rewriting the core extraction logic.

textCopy
You are a dialogue state tracker. Your job is to extract slot values from the conversation history below and populate the target JSON schema.

## TARGET SCHEMA
[OUTPUT_SCHEMA]

## CONVERSATION HISTORY
[CONVERSATION_HISTORY]

## INSTRUCTIONS
1. For each slot in the schema, determine if a value is:
   - CONFIRMED: explicitly stated and not contradicted
   - AMBIGUOUS: mentioned but unclear or has multiple possible interpretations
   - MISSING: not mentioned at all
2. Populate the "slots" object with one entry per schema field. Each entry must include:
   - "value": the extracted value or null if MISSING
   - "status": one of "CONFIRMED", "AMBIGUOUS", "MISSING"
   - "evidence": the exact span from the conversation that supports this value, or null if MISSING
   - "ambiguity_reason": explanation if AMBIGUOUS, otherwise null
3. Set "missing_slots" to an array of field names where status is MISSING.
4. Set "ambiguous_slots" to an array of field names where status is AMBIGUOUS.
5. Set "next_clarification_question" to a single, natural question that would resolve the highest-priority missing or ambiguous slot. If all slots are CONFIRMED, set this to null.
6. Do not invent values. If a slot value is not present in the conversation, mark it MISSING.
7. If the user has corrected a previously stated value, use the most recent value and note the correction in "evidence".

## CONSTRAINTS
[CONSTRAINTS]

## OUTPUT FORMAT
Return ONLY valid JSON matching the schema below. No markdown fences, no commentary.

{
  "slots": {
    "<field_name>": {
      "value": "string or null",
      "status": "CONFIRMED | AMBIGUOUS | MISSING",
      "evidence": "string or null",
      "ambiguity_reason": "string or null"
    }
  },
  "missing_slots": ["string"],
  "ambiguous_slots": ["string"],
  "next_clarification_question": "string or null"
}

To adapt this template, replace [OUTPUT_SCHEMA] with your target JSON schema definition, including field names, types, and descriptions. Replace [CONVERSATION_HISTORY] with the full turn history, formatted with speaker labels and timestamps. Use [CONSTRAINTS] to inject domain-specific rules such as required fields, validation regex patterns, enum values, or cross-field dependency checks. For high-stakes domains like healthcare intake or financial onboarding, add a human review step before committed state is written to your database. Always validate the model's output against your schema before accepting it—reject outputs with hallucinated field names, missing required status fields, or evidence spans that don't appear in the source conversation.

The Dialogue Slot Extraction prompt is designed to be called at the end of every user turn in a multi-turn conversation. It should receive the full conversation history and the target schema as input, and return a structured JSON object representing the current state of all tracked slots. This prompt is not a one-shot extractor; it is a stateful component that must be integrated into a turn-processing pipeline where its output is validated, merged with existing state, and persisted before the assistant formulates its next response.

Wire the prompt into your application as a post-turn processing step. After the user sends a message, append it to the conversation history array and call the model with the prompt template. The output must pass through a strict JSON schema validator before it is accepted. If validation fails, retry once with the validation error message appended as a new user turn instructing the model to fix the malformed output. If the retry also fails, log the failure, fall back to the last known valid state, and surface a clarification question to the user rather than proceeding with corrupted state. For high-stakes domains such as healthcare or finance, route any validation failure or low-confidence slot to a human review queue before the slot value is committed to a downstream system of record.

Persist the validated slot state externally—in a session database, Redis cache, or application memory—not solely in the model's context window. The prompt should receive the persisted state as part of its input to maintain continuity across context window resets or model switches. When a slot transitions from missing to confirmed, log the change with the user turn that provided the evidence. This audit trail is essential for debugging extraction errors and for compliance workflows that require traceable data collection. Avoid the common failure mode of treating the model's output as the source of truth without external validation; the model can hallucinate slot values, mark slots as confirmed without sufficient evidence, or silently drop previously collected slots across turns.