Dialogue State Machine Transition Prompt

This prompt is for developers who have already designed a dialogue state machine and need the model to act as a deterministic transition function, not a conversational planner. The job-to-be-done is reliable, auditable conversation routing: given a current state (e.g., collecting_email), a map of valid transitions (e.g., collecting_email → verifying_email or collecting_email → clarification_needed), and the latest user utterance, the prompt must output the next state and the specific trigger condition that caused the transition. The ideal user is an engineering team building a task-oriented assistant, copilot, or support bot where the conversation flow must be predictable, testable, and explainable to business stakeholders or compliance reviewers.

Do not use this prompt for open-ended chat, assistants that dynamically plan their own conversation flow, or systems where the state graph is unknown at inference time. It assumes you have already defined your state machine externally—this prompt only evaluates transitions, it does not invent new states or re-route the conversation creatively. If your use case requires the model to propose new states, adapt the graph on the fly, or handle completely unanticipated user intents, you need a different architecture, likely combining intent classification with a planner prompt. This prompt also assumes single-turn transition evaluation; multi-step lookahead or probabilistic path scoring should be handled in application code, not in the prompt.

Before deploying, ensure your state machine definition is complete and unambiguous. Missing transitions will cause the model to either hallucinate a state or default to a fallback, both of which break determinism. Wire this prompt behind a validation layer that rejects any output state not present in your allowed transition map. For high-stakes domains like healthcare intake or financial transactions, add a human review step for any transition that changes a compliance-relevant state. Start by testing against a golden set of conversation turns with known correct transitions, and measure exact-match accuracy on the next state field—partial matches are not acceptable for a state machine.

The prompt below is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It accepts a formal state machine definition, the current active state, and the latest user input, then returns the next state and the trigger condition that caused the transition. Replace every square-bracket placeholder with your application's concrete values before sending the prompt to the model. The template includes guardrail instructions that prevent the model from inventing states not present in your definition and from applying transitions that violate your declared rules.

textCopy
You are a dialogue state machine transition engine. Your only job is to determine the next state given a state machine definition, the current state, and the latest user input.

## STATE MACHINE DEFINITION
Below is the complete set of valid states and allowed transitions. You must not invent states or transitions outside this definition.

[STATE_MACHINE_DEFINITION]

## CURRENT STATE
The system is currently in this state:

[CURRENT_STATE]

## CONVERSATION HISTORY
Recent turns for context. Use only to resolve references and understand user intent. Do not re-evaluate past transitions.

[CONVERSATION_HISTORY]

## LATEST USER INPUT
The user just said:

[USER_INPUT]

## OUTPUT SCHEMA
Return a single JSON object with exactly these fields:
{
  "next_state": "string (must match a state name from the state machine definition)",
  "trigger_condition": "string (the specific condition or user intent that caused this transition, referencing the transition rules in the definition)",
  "confidence": "low | medium | high",
  "rationale": "string (brief explanation of why this transition was selected, citing evidence from the user input)",
  "requires_clarification": true | false,
  "clarification_question": "string | null (if requires_clarification is true, a precise question to ask the user to disambiguate)"
}

## CONSTRAINTS
1. The next_state value must exactly match a state name listed in the state machine definition. Do not paraphrase, abbreviate, or invent state names.
2. Only apply transitions that are explicitly defined in the state machine definition. If no defined transition matches, set next_state to the current state and set requires_clarification to true.
3. If the user input is ambiguous and could trigger multiple valid transitions, set requires_clarification to true and explain which transitions are in conflict.
4. If the user input does not relate to any defined transition, keep the current state and set confidence to high with a rationale explaining no transition applies.
5. Do not hallucinate user intent. Base the trigger_condition only on explicit evidence in the user input and conversation history.
6. If [RISK_LEVEL] is "high", set confidence to "low" for any transition that modifies account data, payment information, or personally identifiable information, and set requires_clarification to true.

## EXAMPLES
[FEW_SHOT_EXAMPLES]

Adaptation notes: Replace [STATE_MACHINE_DEFINITION] with a structured description of your states and transitions—ideally a JSON object or a bulleted list of state -> [valid_next_states] mappings with trigger descriptions. Replace [CURRENT_STATE] with the state your application has persisted from the previous turn. Replace [CONVERSATION_HISTORY] with the last N turns, formatted consistently. Replace [USER_INPUT] with the raw user message. Replace [RISK_LEVEL] with "low", "medium", or "high" depending on the domain. Replace [FEW_SHOT_EXAMPLES] with 2–4 annotated examples showing correct transitions, including at least one ambiguous case that triggers clarification and one no-op case where the state should not change. If your state machine is large, consider moving the definition into a retrieved context block or a tool description rather than inlining it every turn.

Before integrating this prompt into production, run it against a golden test set of at least 20 turns covering every defined transition, at least 3 out-of-scope inputs, and 2 ambiguous inputs. Measure exact-match accuracy on next_state and requires_clarification. For high-risk domains, add a human review step when confidence is "low" or when requires_clarification is true and the clarification question will be shown to the user. Log every transition decision with the full prompt, model response, and validator output so you can debug state drift in production.

This prompt is not a standalone chatbot. It is a deterministic state transition function that should be called after every user turn, before the assistant generates a response. The application owns the canonical state machine definition—the prompt only evaluates the next transition. Store the current state in your application's session object (e.g., session.state = 'collecting_symptoms'). After the user sends input, call the LLM with this prompt, passing the current state, the full list of valid transitions defined in your state machine config, and the raw user text. The prompt returns a JSON object with next_state and trigger_condition. Your application then validates that the returned next_state exists in your state machine definition before updating session.state.

Validation and Guardrails: Never trust the model's output directly. Implement a hard validation layer in your application code that rejects any next_state not present in your predefined [VALID_TRANSITIONS] list. If validation fails, log the invalid transition attempt, fall back to the current state, and optionally inject a clarification prompt asking the user to rephrase. For high-stakes domains (healthcare, finance, legal), add a human review queue for any transition that the model flags with low confidence or that crosses a risk boundary (e.g., moving from 'information_gathering' to 'recommendation'). The prompt includes a [RISK_LEVEL] parameter—use it to gate whether transitions require confirmation. Retry logic: If the model returns malformed JSON or a state outside the valid set, retry once with a stricter prompt that includes the validation error message. If the second attempt fails, freeze the state and escalate.

Integration pattern: Wire this as a synchronous pre-processing step in your turn pipeline: User Input → State Transition Prompt → Validate Transition → Update Session State → Generate Assistant Response. The updated state then feeds into your response-generation prompt as part of [CONTEXT]. Logging: Log every transition attempt—input state, user utterance, model-returned state, validation result, and final committed state. This audit trail is essential for debugging state machine drift and for compliance use cases. Model choice: Use a fast, instruction-following model (e.g., GPT-4o-mini, Claude Haiku) for this step since it runs on every turn. Reserve larger models for the response-generation step. Avoid: Do not use this prompt to generate user-facing text. Do not let the model invent new states. Do not skip validation even if the output looks correct.