Dialogue Act Classification Per Turn Prompt

This prompt is designed for a single, programmatic job: classifying the communicative intent of one turn in a conversation. Use it as a feature extraction step within a larger dialogue analytics pipeline, a state tracking system, or a conversation auditing tool. The ideal user is an AI/ML engineer or backend developer who needs to convert raw text into a structured signal that downstream systems can consume. You should use this prompt when you need to answer questions like 'Did the user just ask a question, confirm something, or issue a command?' for every turn in a log. It is not a prompt for generating conversational responses, and it should not be used as a standalone chatbot. Its value is realized when its structured output is fed into a state machine, a database, or an analytics dashboard.

To use this prompt effectively, you must provide three concrete inputs per call: the text of the current turn, the speaker's role (e.g., user or assistant), and a predefined taxonomy of dialogue acts. The taxonomy is a critical configuration point; a generic set like inform, request, confirm, reject, and greet is a common starting point, but you should tailor it to your application's specific needs. The prompt returns a structured JSON object containing the predicted act, a confidence score, and evidence spans from the input text that support the classification. This evidence is essential for debugging and building trust in the pipeline. The prompt is stateless by design, meaning it classifies each turn in isolation. If your use case requires understanding a turn in the context of prior turns, you must manage that context externally and inject the relevant history into the prompt's [CONTEXT] placeholder.

There are clear situations where this prompt is the wrong tool. Do not use it for generating the next assistant response, for open-ended conversation summarization, or for tasks that require deep semantic understanding of a user's goal beyond a single turn's surface intent. It is also unsuitable for real-time, low-latency applications if you are using a large, slow model; in such cases, consider a smaller, fine-tuned classifier model instead of a general-purpose LLM. Finally, this prompt is a classification tool, not a policy enforcer. It will label a turn as a request but will not decide if that request is allowed. That decision must be made by a separate policy layer in your application. Before integrating, ensure your pipeline has a clear schema for the output and a validation step to handle malformed JSON or low-confidence predictions, which are the most common failure modes.

This template provides a complete system prompt for dialogue act classification. It is designed to be pasted directly into your model's system message field. The prompt instructs the model to analyze a single turn within its conversation history and output a structured classification object. Before using this prompt, you must define your dialogue act taxonomy and prepare your turn history format.

textCopy
You are a dialogue act classifier. Your task is to analyze the provided conversation turn and classify it according to the [TAXONOMY] taxonomy.

# TAXONOMY
[TAXONOMY]

# INPUT
You will receive the following inputs:
- **Turn History:** The preceding conversation turns for context.
- **Target Turn:** The specific turn to classify, identified by its role and content.

# INSTRUCTIONS
1.  Analyze the Target Turn within the context of the Turn History.
2.  Identify the primary communicative function of the Target Turn.
3.  Select the most appropriate dialogue act label from the [TAXONOMY] provided above. If multiple acts are present, you may output a primary act and a list of secondary acts.
4.  Provide a brief, evidence-based rationale for your classification, quoting the specific text from the Target Turn that supports your decision.
5.  Output your classification in the strict JSON format specified in [OUTPUT_SCHEMA].

# CONSTRAINTS
[CONSTRAINTS]

# OUTPUT SCHEMA
You must output a single JSON object conforming to the following structure:
[OUTPUT_SCHEMA]

# EXAMPLES
[EXAMPLES]

To adapt this template, replace the square-bracket placeholders with your specific requirements. The [TAXONOMY] should be a clear, bulleted list of your dialogue acts with definitions (e.g., inform, request, confirm, reject, greet). The [OUTPUT_SCHEMA] should be a concrete JSON schema or a clear description of the expected fields, such as {"primary_act": "string", "secondary_acts": ["string"], "rationale": "string"}. Use the [CONSTRAINTS] section to enforce rules like "Do not hallucinate acts not in the taxonomy" or "If the turn is ambiguous, set primary_act to 'other'." Finally, provide a few high-quality [EXAMPLES] that demonstrate the desired mapping from a turn to its JSON output, including tricky edge cases. After deploying, validate the model's output against your schema and taxonomy to catch drift or hallucinations.

This prompt is designed to be called once per turn (user or assistant utterance) in a streaming or batch processing pipeline. It should not be called on the entire conversation history at once; instead, feed it the target utterance and a sliding window of prior turns as context. The output is a structured JSON object containing the predicted dialogue act label, confidence score, and evidence spans. This classification feeds downstream state tracking, analytics dashboards, or routing logic.

Wire the prompt into your application as a stateless function that accepts a turn object and returns a classification result. Implement a thin wrapper that: (1) extracts the target utterance and preceding N turns from your conversation store, (2) populates the [TURN_TEXT], [PREVIOUS_TURNS], and [ACT_TAXONOMY] placeholders, (3) calls the model with a strict JSON mode or structured output constraint, (4) validates the response against your expected schema, and (5) logs the result with a trace ID linking it to the conversation and turn. For high-throughput pipelines, batch multiple turn classifications into a single request if your provider supports it, but keep each classification independent to avoid cross-turn contamination.

Validation is critical because downstream state machines will break on malformed act labels. After receiving the model response, check that the act_label field matches one of your allowed taxonomy values exactly (use an enum check, not fuzzy matching). Verify that confidence is a float between 0.0 and 1.0. Confirm that evidence_spans contains valid offsets within the turn text. If validation fails, retry once with a repair prompt that includes the validation error message and the original turn. If the retry also fails, log the failure, assign a fallback label of UNCLASSIFIED, and route to a human review queue if the downstream use case requires high accuracy. For analytics pipelines, UNCLASSIFIED with a low confidence flag is often acceptable; for real-time routing, escalate.

Choose a model that supports structured output (JSON mode or function calling) to reduce parsing errors. Smaller, faster models (e.g., GPT-4o-mini, Claude Haiku, or fine-tuned open-weight models) are usually sufficient for single-turn dialogue act classification and keep per-turn costs low. If your taxonomy is large (20+ acts) or includes subtle distinctions (e.g., request_clarification vs request_confirmation), test with a stronger model first, then evaluate whether a smaller model maintains acceptable accuracy. Store classification results in your conversation state store alongside the turn data, not just in logs, so downstream components can query act sequences without re-processing.

Before shipping, build an evaluation harness that runs this prompt against a labeled dataset of at least 200 turns covering your full act taxonomy. Measure per-act precision and recall, not just overall accuracy, because rare acts like reject or correct are often the most important for downstream behavior. Set a minimum confidence threshold below which classifications are treated as uncertain; route uncertain classifications to a human review queue or a secondary classifier. Monitor production drift by sampling classified turns weekly and comparing model labels against human annotator labels. If act distribution shifts significantly (e.g., a sudden increase in complaint acts), investigate whether the model is misclassifying or user behavior has genuinely changed.