Correction vs New Topic Detection Prompt Template

This prompt is a dialogue router designed for a single, high-stakes classification task: distinguishing a user correction from a new topic. In multi-turn assistant and copilot systems, a user turn that contradicts prior context is ambiguous. It could be a correction to the current task ("No, use the Q3 report, not Q2") or a completely new, unrelated request ("Actually, let's switch gears and draft an email to legal"). Misclassifying a correction as a new topic causes the system to abandon in-progress work and lose user trust. Misclassifying a new topic as a correction pollutes the active task state with irrelevant constraints. This prompt is for AI engineers and dialogue system architects who need a reliable routing decision before downstream state updates, tool calls, or response generation occur.

The ideal user is integrating this prompt into a conversation state manager or dialogue orchestration layer. Required context includes the active task description, the last assistant response, and the current user turn. The prompt produces a structured routing decision with a contradiction analysis, not a conversational reply. It is designed to be called synchronously before any state mutation. Use this prompt when the cost of a routing error is high—for example, in customer support where a correction to an order must update the existing ticket rather than create a duplicate, or in a coding agent where a correction to a file path must revise the current patch rather than start a new task. The prompt includes explicit handling of ambiguous cases where correction and topic shift overlap, such as "Actually, I meant the other project" which could be a correction within the same domain or a full context switch.

Do not use this prompt when the user turn is a simple clarification question ("What do you mean by that?"), a confirmation ("Is that right?"), or a follow-up that extends rather than contradicts prior context. Those turns should be handled by separate clarification or continuation routers. This prompt is also not a replacement for a full intent classifier—it answers one binary question with an ambiguity escape hatch. For low-stakes chat where misrouting has minimal consequence, a simpler keyword-based heuristic may suffice. The prompt assumes the upstream system has already resolved coreference and anaphora; feeding it unresolved pronouns will degrade accuracy. Finally, this prompt is a classifier, not a response generator. Its output should be consumed by application logic that decides whether to update state, roll back claims, or reset context.

This template is designed to be the core classification step in a dialogue router. It forces the model to analyze the contradiction between the current user turn and the prior conversation context, then output a structured routing decision. The prompt is built for direct integration into an application harness that will parse the JSON output and trigger either a correction-handling workflow or a topic-shift workflow.

textCopy
You are a dialogue router. Your job is to determine whether a user's latest message is a correction to the ongoing task or a completely new, unrelated request.

[CONTEXT]

Current task state: [TASK_STATE]
Last assistant response: [LAST_RESPONSE]

User's latest message: [USER_INPUT]

[CONSTRAINTS]
- A correction points out an error, misunderstanding, or bad assumption in the assistant's last response or the current task state. The user wants to fix the existing work.
- A new topic introduces a different subject, goal, or request that does not aim to repair the current task.
- If the user's message does both (e.g., "No, that's wrong. Anyway, what's the weather?"), classify it as a correction if the primary intent is to fix the current task before moving on. Otherwise, classify it as a new topic.
- Ambiguous cases where the user rejects the assistant's output but gives no clear fix should be classified as a correction with low confidence.

[OUTPUT_SCHEMA]
{
  "classification": "correction" | "new_topic",
  "confidence": 0.0-1.0,
  "rationale": "Brief explanation of the contradiction and why this classification was chosen.",
  "contradicted_element": "The specific claim, value, or assumption being challenged, or null if new_topic."
}

[EXAMPLES]
User: The report says Q3, but our fiscal year starts in July. It should be Q1.
Classification: correction
Rationale: User explicitly corrects a specific claim (Q3) with a replacement (Q1) while staying within the report task.

User: That's not what I asked. Can you just book a flight to London?
Classification: new_topic
Rationale: User rejects the prior response but immediately pivots to an unrelated task (flight booking) with no attempt to repair the report.

User: I think you misunderstood the deadline.
Classification: correction
Rationale: User identifies a misunderstanding but doesn't provide the fix yet. Classified as correction to trigger a clarification workflow.

To adapt this template, replace the placeholders with your application's actual state representation. [TASK_STATE] should be a concise summary of the current goal, key slots, and progress. [LAST_RESPONSE] is the assistant's most recent full turn. If your system uses a different output schema, update [OUTPUT_SCHEMA] accordingly, but keep the classification and confidence fields as the minimum viable contract. The [EXAMPLES] block is critical for ambiguous cases; add 2-3 more examples that mirror your domain's specific failure patterns. For high-stakes domains like healthcare or finance, add a [RISK_LEVEL] placeholder and a rule that low-confidence corrections must escalate for human review.

This prompt is designed to sit inside a dialogue router—a lightweight classification layer that runs before the main assistant or agent logic. Every user turn that contradicts or appears to contradict prior context passes through this prompt. The output is a structured routing decision: correction, new_topic, or ambiguous. The router then branches: corrections flow to a state rollback and repair pipeline; new topics reset or branch the conversation context; ambiguous cases may trigger a lightweight clarification turn or escalate for human review. Do not use this prompt as a standalone classifier without wiring it into a stateful routing harness, because the classification alone does not update dialogue state, roll back incorrect claims, or re-ground the conversation.

Integration pattern: Place this prompt after turn ingestion and coreference resolution but before the main response generation or tool-use step. The input [PRIOR_CONTEXT] should be a structured summary of the last N turns, active slots, and pending actions—not raw transcript. The [CURRENT_USER_TURN] should be the resolved user utterance after coreference and ellipsis expansion. The [OUTPUT_SCHEMA] must enforce a strict JSON contract: {"decision": "correction|new_topic|ambiguous", "contradiction_analysis": "...", "confidence": 0.0-1.0, "affected_context_keys": [...]}. Validate this schema before routing. If the model returns invalid JSON or a decision outside the enum, retry once with a stricter format instruction. If it fails again, default to ambiguous and log the failure for review. For high-stakes domains (healthcare, legal, finance), route all ambiguous decisions to a human review queue with the contradiction analysis attached.

Model choice and latency budget: This is a classification task with moderate reasoning depth. A fast model (e.g., GPT-4o-mini, Claude Haiku, or a fine-tuned small classifier) is usually sufficient. Target sub-500ms latency. If you are already running a larger model for response generation, consider batching this classification as a separate lightweight call to avoid blocking the main generation path. Cache the classification result in the dialogue state so downstream repair or topic-switch handlers can reference it without re-running the prompt. Eval and monitoring: Build a golden test set of 50–100 turns covering explicit corrections, implicit corrections, topic shifts, and ambiguous overlaps. Measure precision and recall per class. Monitor production drift by sampling classified turns weekly and comparing against human labels. Set an alert if the ambiguous rate spikes above 20%, as this often indicates prompt degradation, context pollution, or a model version change that altered classification behavior.

Failure modes to instrument: The most common production failure is false correction classification—treating a genuine topic shift as a correction, which causes the router to incorrectly roll back state and frustrate the user. The second is false new-topic classification—missing a correction and letting the assistant continue with incorrect assumptions. Log both error types with the full context payload. If you observe correction cascades (multiple corrections in rapid succession), the router may be failing to detect that the user is correcting the correction response, not the original claim. In these cases, inject a correction_loop_count into the dialogue state and escalate after three consecutive corrections in the same topic cluster.