Correction Intent Classification Prompt Template

This prompt serves as the first stage in a structured correction-handling pipeline, specifically designed to classify a user's correction of a prior assistant turn into one of six distinct intent types: factual, logical, procedural, format, slot-value, or intent-misclassification. The primary job-to-be-done is to provide a reliable, structured signal that downstream routing logic can use to select the appropriate repair strategy. For example, a factual correction might trigger a claim reversal and evidence re-retrieval, while a format correction might only require output restructuring without invalidating the underlying data. The ideal user is an AI engineer or dialogue system architect building a multi-turn assistant product where user trust depends on graceful error recovery.

This prompt assumes strict prerequisites: an upstream detection module has already flagged the user turn as a potential correction, and a prior assistant turn exists in the session context. It is not designed for general intent classification, new topic detection, or single-turn Q&A where no assistant output exists to correct. Using it without a prior assistant turn will produce meaningless classifications. The prompt requires two inputs at minimum: the prior assistant output that is being corrected and the user's correction turn. Optionally, you can include session context or tool call history to improve accuracy on procedural and slot-value corrections. The output is a structured JSON object containing a classification label and a confidence score between 0.0 and 1.0, enabling threshold-based routing decisions.

Do not use this prompt when the user is asking a clarifying question, providing new information unrelated to prior assistant output, or shifting topics entirely. These cases should be filtered out by the upstream correction detection module. If your system lacks a separate detection step, you risk false positives where normal user turns are incorrectly classified as corrections, leading to unnecessary state rollbacks or confusing acknowledgments. For high-stakes domains such as healthcare or legal applications, always route low-confidence classifications (below your defined threshold) to a human reviewer rather than automatically executing state changes. The next step after classification is to route the labeled correction to a specialized repair prompt matched to the intent type, such as a claim reversal prompt for factual corrections or a state rollback prompt for slot-value corrections.

This prompt template is designed to be copied directly into your prompt management system, IDE, or orchestration layer. It classifies a user turn that has been flagged as a correction into one of six intent types: factual, logical, procedural, format, slot-value, or intent-misclassification. The template expects you to supply the prior assistant output, the current user turn, and any relevant conversation context. Replace every square-bracket placeholder before sending the prompt to the model. The output is a JSON object with a classification label and a confidence score, suitable for routing to the appropriate correction handler.

textCopy
You are a dialogue state classifier for an AI assistant. Your task is to classify the user's correction intent based on the assistant's prior output and the user's current turn.

## INPUT
- Assistant's prior output: [ASSISTANT_PRIOR_OUTPUT]
- User's current turn: [USER_CURRENT_TURN]
- Conversation context (last 3 turns): [CONVERSATION_CONTEXT]

## CLASSIFICATION TAXONOMY
Choose exactly one label from the following:
- `factual`: The user is correcting a specific fact, claim, date, name, number, or piece of information the assistant stated.
- `logical`: The user is correcting flawed reasoning, a contradiction, an invalid inference, or a causal error in the assistant's response.
- `procedural`: The user is correcting the sequence of steps, workflow order, or process the assistant described.
- `format`: The user is correcting the output structure, such as JSON shape, markdown formatting, list style, or schema compliance.
- `slot-value`: The user is correcting a specific field, parameter, or slot value in a structured output or form the assistant produced.
- `intent-misclassification`: The user is indicating the assistant misunderstood their original request or goal entirely.

## CONSTRAINTS
- If the user's turn contains multiple correction types, choose the primary (most impactful) type.
- If the correction is ambiguous between two types, prefer the more specific type (e.g., `slot-value` over `factual` when a specific field is named).
- If the user's turn does not contain a correction, output `none` with confidence 0.0.
- Do not invent a label outside the taxonomy.

## OUTPUT SCHEMA
Return ONLY a valid JSON object with no additional text, markdown fences, or commentary:
{
  "correction_type": "<label>",
  "confidence": <float between 0.0 and 1.0>,
  "rationale": "<one-sentence explanation of why this label was chosen>"
}

## EXAMPLES
Example 1:
Assistant: "The meeting is scheduled for Tuesday at 3 PM."
User: "No, it's Wednesday at 2 PM."
Output: {"correction_type": "factual", "confidence": 0.97, "rationale": "User directly corrects a specific date and time claim."}

Example 2:
Assistant: "First, deploy the backend, then run database migrations."
User: "You have to run migrations before deploying."
Output: {"correction_type": "procedural", "confidence": 0.95, "rationale": "User corrects the order of operational steps."}

Example 3:
Assistant: "That's not what I asked for. I wanted a summary, not a list."
User: (turn after assistant produced a bullet list)
Output: {"correction_type": "format", "confidence": 0.92, "rationale": "User explicitly requests a different output structure."}

Adaptation guidance: Replace [ASSISTANT_PRIOR_OUTPUT] with the exact text the assistant last produced. [USER_CURRENT_TURN] should be the raw user message that triggered correction detection. [CONVERSATION_CONTEXT] should include the last 2-3 turns for disambiguation, especially when the correction references earlier statements. If your system uses a different taxonomy, replace the six labels and their descriptions while keeping the output schema consistent. For high-stakes domains like healthcare or finance, add a [RISK_LEVEL] placeholder and a constraint that low-confidence classifications (below 0.7) must route to human review rather than automated correction handlers.

Validation and testing: Before deploying this prompt, run it against a confusion matrix test set covering all six correction types plus none cases. Pay special attention to overlapping types—for example, a user correcting a date inside a structured form could be factual or slot-value. Your eval harness should measure precision and recall per label, not just overall accuracy. Flag any classification where confidence exceeds 0.8 but the label is wrong; these are the failures that will silently route corrections to the wrong handler in production.

The Correction Intent Classification prompt is designed to operate as a lightweight, pre-processing step within a larger dialogue management pipeline. Its primary job is to inspect an incoming user turn and the assistant's prior output to produce a structured classification label and confidence score. This classification then drives downstream routing: a factual correction might trigger a claim reversal and state rollback, while a format correction might only require re-rendering the last response. The prompt should be called synchronously before any new assistant generation begins, ensuring the system understands the user's corrective intent before committing to a new response or tool call. This is not a standalone chat prompt; it is a classification microservice that returns JSON to be consumed by application logic.

To wire this into an application, wrap the prompt call in a function that accepts user_turn, assistant_prior_turn, and optional conversation_summary as inputs. The function should enforce a strict JSON output schema using your model provider's structured output mode (e.g., response_format with a JSON schema in OpenAI, or constrained generation in other providers). Implement a validation layer that checks: (1) the correction_type field is one of the allowed enum values (factual, logical, procedural, format, slot_value, intent_misclassification, none), (2) the confidence score is a float between 0.0 and 1.0, and (3) if correction_type is not none, the target_span field contains a non-empty string referencing the assistant's prior output. If validation fails, retry once with the validation error message appended to the prompt as a [PREVIOUS_ERROR] constraint. After a second failure, log the raw output and default to correction_type: "none" to avoid blocking the conversation. For high-stakes domains like healthcare or legal workflows, route any classification with confidence below 0.85 to a human review queue before acting on the correction.

Model choice matters for latency and accuracy. Use a fast, instruction-tuned model (e.g., GPT-4o-mini, Claude Haiku) for this classification task, as it runs on every user turn and must return in under 500ms to avoid perceptible lag. Avoid routing this through a large, expensive model unless your eval suite shows a significant accuracy gap on your specific correction distribution. Implement a confusion matrix eval harness that tests the classifier against a golden dataset of labeled correction examples, including edge cases like implicit corrections, sarcasm, multi-type corrections, and corrections that span multiple prior turns. Track precision and recall per correction type, and set an alert if the none classification rate drops below expected baselines, which may indicate the classifier is over-triggering on clarifying questions. Log every classification result with a correlation ID that ties the user turn, classification output, downstream action taken, and eventual user feedback into a single trace for debugging correction failures in production.