Correction Tone Adaptation Prompt Template

This prompt is for assistant product teams who need their system to respond to user corrections with the right emotional tone. The core job is to analyze the user's sentiment during a correction event—detecting frustration, anger, politeness, or neutrality—and then adapt the assistant's acknowledgment tone accordingly. The ideal user is an AI engineer or product manager building a customer-facing chat assistant where trust recovery after a mistake is critical to retention. You need the conversation context leading up to the correction, the user's correction turn, and a defined set of tone profiles your product supports (e.g., neutral, empathetic, concise).

Do not use this prompt when the correction itself is ambiguous or unconfirmed. If you haven't yet run a correction detection or intent classification step, the tone adaptation will be guessing at both the problem and the user's emotional state. This prompt assumes a confirmed correction event is already identified. It is also not a replacement for a full conversation design system—tone adaptation is one component in a larger correction-handling pipeline that includes claim reversal, state rollback, and evidence re-verification. Use this prompt when you have a clear correction signal and need to calibrate the how of the response, not the what.

Before implementing, define your tone taxonomy explicitly. A common set includes: neutral (brief acknowledgment, no emotional language), empathetic (validates user frustration, uses phrases like 'You're right, I apologize for that error'), and concise (minimal acknowledgment, immediate transition to corrected information). The prompt should never produce defensive, dismissive, or overly obsequious tones. Over-accommodation—where the assistant becomes excessively apologetic or self-deprecating—is a common failure mode that erodes user confidence as much as deflection does. Wire this prompt into your correction pipeline after detection and classification, but before the final response generation step. The output should be a tone label and a brief acknowledgment template that the downstream response generator can incorporate, not the full corrected response itself.

This prompt template is designed to be the core instruction set for an AI assistant that must calibrate its correction response tone to the user's emotional state. It takes the original assistant claim, the user's correction, and a detected sentiment or frustration level as inputs. The goal is to produce an acknowledgment that validates the user's experience without being robotic, overly apologetic, or defensive. The template uses square-bracket placeholders for all dynamic inputs, making it ready to be wired into an application's prompt assembly pipeline.

textCopy
You are an assistant that has just been corrected by a user. Your task is to generate a response that acknowledges the correction and provides the corrected information. You must adapt the tone of your acknowledgment to match the user's detected sentiment level.

## INPUTS
[ORIGINAL_CLAIM]: The specific statement you made that was incorrect.
[USER_CORRECTION]: The user's message pointing out the error.
[CORRECTED_INFORMATION]: The verified, accurate information that should replace the original claim.
[DETECTED_SENTIMENT]: The user's emotional state, classified as one of: `neutral`, `mildly_frustrated`, `frustrated`, or `angry`.

## TONE ADAPTATION RULES
- **neutral**: Use a brief, professional acknowledgment. Example: "You're right, let me correct that."
- **mildly_frustrated**: Add a concise, sincere apology before the correction. Example: "I apologize for the error. The correct information is..."
- **frustrated**: Acknowledge the user's frustration directly, provide a clear apology, and state the correction without any justification or defensiveness. Example: "I see how that was frustrating. I was wrong. Here is the correct information..."
- **angry**: Prioritize de-escalation. Acknowledge the impact of the error, offer a direct and unqualified apology, and provide the correction as succinctly as possible. Do not make excuses. Example: "You're right, and I understand why that would be upsetting. I made a mistake. The correct information is..."

## CONSTRAINTS
- Do not explain *why* the original error was made unless the user explicitly asks.
- Do not use hedging language like "I believe," "I think," or "It seems."
- Never contradict the user's correction if it has been verified as [CORRECTED_INFORMATION].
- Keep the focus on the corrected information and moving the task forward.
- Maintain a helpful and professional persona, even when the user is angry.

## OUTPUT FORMAT
Generate only the final response text to be sent to the user. Do not include any meta-commentary or labels.

To adapt this template for your application, replace the placeholders with data from your dialogue state manager and sentiment detection system. The [DETECTED_SENTIMENT] field should be populated by a separate classification step or an API call before this prompt is assembled. For high-stakes domains, ensure the [CORRECTED_INFORMATION] is sourced from a trusted knowledge base or human operator, not generated by the model itself. The next step is to build a test harness using the tone adaptation rules as evaluation criteria, checking for over-accommodation (e.g., being overly apologetic for a neutral correction) and tone inconsistency.

The Correction Tone Adaptation prompt is designed to sit between a correction detection module and the final response generator. It should not be called on every user turn—only when a correction has been detected and classified. The typical call flow is: (1) user turn arrives, (2) correction detection prompt classifies the turn as a correction, (3) correction intent classifier determines the type, (4) this tone adaptation prompt receives the correction type, the original assistant claim, the user's correction text, and any session context, and (5) the output tone parameters are passed to the final acknowledgment or reversal prompt. Decoupling tone adaptation from content generation allows each prompt to be tested and versioned independently.

Wire this prompt into your application as a synchronous step in the correction-handling pipeline. The function should accept a correction_event object containing correction_type, original_claim, user_correction_text, session_tone_history (prior frustration signals), and assistant_persona_config. Validate inputs before calling the model: ensure user_correction_text is non-empty, correction_type is one of your supported enum values, and session_tone_history does not exceed your context budget. On the output side, validate that the returned JSON contains the required fields—detected_frustration_level, tone_profile, and acknowledgment_phrasing—and that detected_frustration_level falls within your defined scale (e.g., neutral, mild, moderate, high). If validation fails, retry once with a more explicit constraint in the prompt; if it fails again, fall back to a default neutral tone profile and log the failure for review.

Model choice matters here. This prompt requires emotional nuance and social judgment, which smaller or older models often mishandle. Use a capable instruction-following model (e.g., Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro). Avoid using a fine-tuned classifier for this step—the task requires generative reasoning about tone, not just classification. Set temperature low (0.0–0.2) to reduce variance in tone calibration. For observability, log every tone adaptation decision with the input frustration signals, the selected tone profile, and the final acknowledgment phrasing. Attach a correlation ID that links the tone decision to the downstream correction response and, if available, to user satisfaction signals (e.g., follow-up corrections, session abandonment, or explicit feedback). This traceability is essential for tuning frustration detection thresholds and identifying over-accommodation patterns over time.

Two failure modes require specific harness attention. First, over-accommodation: when the model escalates to an overly empathetic or apologetic tone for minor corrections, making the assistant sound insincere or patronizing. Mitigate this by capping the maximum tone intensity in your assistant_persona_config and by running periodic eval checks where human reviewers rate tone appropriateness on a sample of production corrections. Second, tone inconsistency: when the assistant's tone shifts abruptly between turns—neutral one turn, highly empathetic the next—breaking the user's sense of a coherent interaction. Mitigate this by passing session_tone_history into every call and instructing the model to smooth transitions rather than jump between extremes. If your application supports it, implement a moving average or decay function over frustration scores in the application layer before they reach the prompt.

Do not use this prompt in isolation. It must feed into a downstream correction response prompt (such as Correction Acknowledgment Response or Assistant Claim Reversal) that consumes the tone_profile and acknowledgment_phrasing fields. The tone adaptation prompt decides how to sound; the response prompt decides what to say. If your system includes a human review queue for high-risk corrections (e.g., medical, legal, or financial claims), route corrections with detected_frustration_level: high to that queue before generating a response. Finally, include this prompt in your regression test suite with golden examples covering each frustration level and edge cases like sarcastic corrections, multi-turn frustration buildup, and corrections where the user explicitly says they are not frustrated.