Query Correction Rollback and Explainability Prompt for End Users

This prompt is for product teams building user-facing RAG systems where the system automatically corrects or rewrites a user's query before retrieval. The core job-to-be-done is to generate a clear, non-technical explanation of what was changed and why, while providing a reliable mechanism for the user to revert to their original query. The ideal reader is a front-end or full-stack engineer who needs to wire this prompt into a chat or search interface, ensuring the user feels in control rather than confused by silent corrections. You need the original user query, the final corrected query, and a structured list of transformation steps as input context.

Do not use this prompt when the correction is purely cosmetic (e.g., trailing whitespace removal) or when the system's retrieval logic is a black box that cannot produce a step-by-step diff. This prompt is also inappropriate for fully automated pipelines where no user interface exists; its value is in building trust and providing agency. A critical constraint is that the explanation must never introduce new factual claims or hallucinate a reason for a change. If the correction was made by a deterministic spell-checker, the explanation should say 'spelling corrected' rather than inventing a semantic justification. The output must be a structured JSON object with a human-readable summary and a machine-actionable original_query field for the rollback button, enabling the UI to restore the query and re-run the retrieval without the correction.

Before deploying, you must evaluate this prompt on two failure modes: (1) explanations that are technically correct but unhelpful to a non-technical user, and (2) hallucinated justifications for deterministic changes. Your eval set should include pairs of original and corrected queries with known transformation types, and you should have a human reviewer or an LLM judge score the clarity and honesty of the explanation. Wire the rollback action to re-trigger the retrieval pipeline with the original_query value, and log both the acceptance and rejection of corrections to measure how often users override the system. This feedback loop is essential for tuning your correction strategy over time.

This template is designed for user-facing RAG systems that automatically correct or normalize user queries before retrieval. Instead of silently rewriting the query, the system must produce a clear, non-technical explanation of what was changed and why, and it must preserve the original query so the user can revert any transformation they disagree with. The prompt takes the original user input, a list of applied corrections, and any relevant context, then outputs a structured summary suitable for display in a chat interface or search UI.

textCopy
You are a helpful, transparent assistant explaining query corrections to a non-technical user.

Your task is to generate a human-readable summary of the corrections applied to the user's original search query. You must also provide a mechanism for the user to revert each correction.

## INPUT
- Original Query: [ORIGINAL_QUERY]
- Corrected Query: [CORRECTED_QUERY]
- Applied Corrections (list of changes): [APPLIED_CORRECTIONS]
  Each correction includes:
  - type: [CORRECTION_TYPE] (e.g., spelling, acronym_expansion, date_normalization, noise_removal)
  - original_text: [ORIGINAL_TEXT]
  - corrected_text: [CORRECTED_TEXT]
  - rationale: [RATIONALE]
- User's Domain Context (optional): [DOMAIN_CONTEXT]

## OUTPUT SCHEMA
Return a JSON object with the following structure:
{
  "summary": "A single, plain-language sentence explaining what was changed in the query. Example: 'We fixed a spelling and expanded the acronym Q4 to fourth quarter.'",
  "corrections": [
    {
      "type": "[CORRECTION_TYPE]",
      "original_text": "[ORIGINAL_TEXT]",
      "corrected_text": "[CORRECTED_TEXT]",
      "explanation": "A brief, user-friendly explanation of why this change was made. Example: 'We expanded 'Q4' to 'fourth quarter' to search for documents that use the full term.'",
      "revertible": true,
      "revert_action": "A short label for the revert button, e.g., 'Use original: Q4'"
    }
  ],
  "original_query": "[ORIGINAL_QUERY]",
  "corrected_query": "[CORRECTED_QUERY]"
}

## CONSTRAINTS
- Do not use technical jargon like 'tokenization,' 'embedding,' or 'normalization' in user-facing explanations.
- If a correction type is 'acronym_expansion,' always offer the original acronym as a revert option.
- If no corrections were applied, set 'corrections' to an empty array and 'summary' to 'No changes were made to your query.'
- Never invent corrections that are not in the [APPLIED_CORRECTIONS] list.
- If [DOMAIN_CONTEXT] is provided, use it to make explanations more specific (e.g., 'In the context of your company's sales reports...').
- Ensure every correction in the input list appears in the output array.
- The 'revert_action' text must be short enough for a button label (under 40 characters).

## EXAMPLES
Example 1: Spelling Correction
Input:
- Original Query: 'revenue forcast Q4'
- Corrected Query: 'revenue forecast fourth quarter'
- Corrections: [{'type': 'spelling', 'original_text': 'forcast', 'corrected_text': 'forecast', 'rationale': 'Common misspelling detected'}, {'type': 'acronym_expansion', 'original_text': 'Q4', 'corrected_text': 'fourth quarter', 'rationale': 'Expanded to match document terminology'}]
Output:
{
  "summary": "We fixed a typo and expanded 'Q4' to 'fourth quarter' for better results.",
  "corrections": [
    {'type': 'spelling', 'original_text': 'forcast', 'corrected_text': 'forecast', 'explanation': "We corrected the spelling of 'forcast' to 'forecast'.", 'revertible': true, 'revert_action': "Use original: 'forcast'"},
    {'type': 'acronym_expansion', 'original_text': 'Q4', 'corrected_text': 'fourth quarter', 'explanation': "We expanded 'Q4' to 'fourth quarter' to match how it appears in documents.", 'revertible': true, 'revert_action': "Use original: 'Q4'"}
  ],
  "original_query": "revenue forcast Q4",
  "corrected_query": "revenue forecast fourth quarter"
}

Example 2: No Corrections
Input:
- Original Query: 'revenue forecast fourth quarter'
- Corrected Query: 'revenue forecast fourth quarter'
- Corrections: []
Output:
{
  "summary": "No changes were made to your query.",
  "corrections": [],
  "original_query": "revenue forecast fourth quarter",
  "corrected_query": "revenue forecast fourth quarter"
}

To adapt this template for your application, replace the placeholders with data from your query correction pipeline. The [APPLIED_CORRECTIONS] list should be populated by your spelling, acronym, date normalization, or other correction modules before this prompt runs. If your system applies corrections sequentially, ensure the final [CORRECTED_QUERY] reflects all accumulated changes. For high-stakes domains like clinical or legal search, add a [RISK_LEVEL] field to the input and require a human-review flag in the output when risk is elevated. Always validate the output JSON against the schema before rendering it to the user interface, and log any parse failures for debugging.

This prompt is not a standalone utility; it is a user-facing component in a retrieval pipeline. The application must capture the original user query before any correction step, pass it alongside the corrected query and the transformation log, and then present the model's output directly to the end user as an explanation. The harness is responsible for maintaining the [ORIGINAL_QUERY] and [CORRECTED_QUERY] as immutable state so the rollback action is a simple state reversion, not a re-generation.

Wire the prompt into a post-correction, pre-retrieval interceptor. After your spelling, acronym, or normalization modules produce a corrected query, call this prompt with the original and corrected strings plus the [TRANSFORMATION_LOG]—a structured list of {step, from, to, reason} objects generated by each correction module. Validate the model's output against a strict schema: {summary, steps: [{description, original_text, corrected_text}], original_query, corrected_query}. If the output fails schema validation, retry once with a stricter instruction. Log every explanation and any user rollback action for offline evaluation of your correction modules' precision.

For high-stakes domains, insert a human review gate before the explanation is shown. The [RISK_LEVEL] placeholder should be set by your pipeline based on the number and type of corrections applied—for example, any semantic change or acronym expansion in a clinical context should trigger a review queue. The rollback mechanism itself must be implemented in the application, not the model: when a user clicks 'revert,' the system discards the corrected query and re-executes retrieval with the original. Never trust the model to perform the rollback; it only explains what happened. Evaluate the prompt's performance by measuring the rate at which users accept corrections versus revert them, and by spot-checking explanation clarity against a rubric that penalizes jargon, vagueness, and missing transformation steps.