Query Intent Preservation During Correction Prompt Template

This prompt belongs in the pre-retrieval validation layer of a RAG pipeline. After a spelling corrector or grammar normalizer modifies a user query, this prompt compares the original and corrected versions to detect semantic drift. Its job is to answer one question: did the correction step preserve the user's intended meaning, or did it introduce a change that will send retrieval down the wrong path? Use it when your correction step could change technical terms, entity names, or domain-specific language—situations where a naive spell-checker might 'fix' a valid product code, a medical term, or a proper noun into something plausible but wrong.

Do not use this prompt as the primary spelling corrector. It is a safety check, not a repair tool. It gates whether a corrected query proceeds to retrieval or is flagged for review. The ideal deployment point is immediately after any automated normalization step and before the query hits your vector store, keyword index, or hybrid retrieval layer. If the prompt returns a high drift score, the corrected query should be blocked, logged, and optionally routed to a human-in-the-loop review queue or a clarification prompt. If the drift score is low, the corrected query proceeds. This prompt is most valuable in domains where retrieval precision matters more than recall—healthcare, legal, finance, technical support, and any product where a wrong answer carries real cost.

Avoid deploying this prompt on every query in high-throughput, low-risk systems where the cost of an extra LLM call outweighs the benefit of drift detection. If your correction step is a simple regex or a deterministic dictionary lookup with no ambiguity, you likely don't need this gate. Also avoid using it when the correction step itself is an LLM—chaining two LLM calls for correction-then-validation creates latency and cost that may be better solved by a single, more carefully prompted correction step with built-in confidence scoring. For voice-to-text pipelines, pair this with a phonetic error correction prompt upstream; for multilingual systems, ensure the drift comparison accounts for translation-equivalent meaning rather than surface-form matching. Start by running this prompt on a sample of corrected queries and measuring the false-positive rate—queries flagged as drifted that humans would consider equivalent—before enabling it as a hard gate in production.

This prompt template is designed to be pasted directly into your orchestration layer. It takes an original user query and its corrected version, then verifies whether the correction preserved the original intent. The model produces a structured comparison with a semantic drift score, a judgment on intent preservation, and a detailed rationale. This is a critical safety check in production RAG pipelines where automated correction can silently alter meaning.

textCopy
You are a query intent preservation auditor for a production retrieval system.

Your task is to compare an original user query with its corrected version and determine whether the correction preserved the original semantic intent.

# INPUTS
- Original Query: [ORIGINAL_QUERY]
- Corrected Query: [CORRECTED_QUERY]
- Correction Type: [CORRECTION_TYPE]  // e.g., spelling, grammar, acronym expansion, punctuation normalization
- Domain Context (optional): [DOMAIN_CONTEXT]  // e.g., medical, legal, technical support, e-commerce

# OUTPUT SCHEMA
Return a valid JSON object with exactly these fields:
{
  "intent_preserved": boolean,  // true if the core meaning is unchanged
  "semantic_drift_score": number,  // 0.0 to 1.0, where 0.0 = identical intent, 1.0 = completely different intent
  "drift_category": string,  // one of: "none", "negligible", "minor", "moderate", "severe"
  "key_differences": [string],  // list of specific semantic changes detected, empty array if none
  "rationale": string,  // concise explanation of the judgment
  "recommendation": string  // one of: "use_corrected", "use_original", "flag_for_review", "request_clarification"
}

# CONSTRAINTS
1. Focus on semantic meaning, not surface form. A rephrasing that preserves intent is acceptable.
2. Flag any change to entities, numbers, dates, negations, comparatives, or domain-specific terminology.
3. If the correction introduces ambiguity that was not present in the original, treat this as drift.
4. If the original query was ambiguous and the correction resolves it in one direction, note this as intent refinement, not preservation failure, but flag it for review.
5. For [RISK_LEVEL] = "high" (e.g., clinical, legal, financial queries), default to "flag_for_review" for any non-zero drift score.

# EXAMPLES
Example 1:
Original: "wat is the does of aspirn for hart atack"
Corrected: "what is the dose of aspirin for heart attack"
Correction Type: spelling
Output: {"intent_preserved": true, "semantic_drift_score": 0.0, "drift_category": "none", "key_differences": [], "rationale": "All corrections are surface-level spelling fixes. No semantic change detected.", "recommendation": "use_corrected"}

Example 2:
Original: "latest iPhone battery issues"
Corrected: "latest iPhone battery life issues"
Correction Type: grammar
Output: {"intent_preserved": false, "semantic_drift_score": 0.6, "drift_category": "moderate", "key_differences": ["Added 'life' narrows query from general battery problems to battery longevity specifically"], "rationale": "The original query was broad about battery issues. The correction added 'life', which changes the scope to battery duration only.", "recommendation": "flag_for_review"}

Now evaluate the provided query pair.

To adapt this template, replace the square-bracket placeholders at runtime. [ORIGINAL_QUERY] and [CORRECTED_QUERY] are mandatory. [CORRECTION_TYPE] should be populated from your correction pipeline's metadata so the model understands what transformation was applied. [DOMAIN_CONTEXT] is optional but strongly recommended for high-stakes domains where terminology sensitivity matters. [RISK_LEVEL] should be set by your application logic based on the query's downstream impact—use "high" for clinical, legal, financial, or safety-critical queries, and "standard" otherwise. Before deploying, run this prompt against a golden dataset of 50–100 annotated intent-preservation pairs to calibrate the drift score thresholds for your domain.

The intent preservation prompt is not a standalone correction step; it is a guard that runs after a query correction module and before the corrected query is sent to retrieval. In a production RAG pipeline, the typical call order is: raw user query → spelling/grammar correction → intent preservation check → retrieval → generation. The prompt compares the original and corrected query strings, producing a semantic drift score and a judgment. This output must be consumed by application logic that decides whether to use the corrected query, fall back to the original, request human review, or ask the user for clarification.

Wire the prompt into your application as a synchronous pre-retrieval hook. After the correction module returns a corrected_query, call the intent preservation prompt with [ORIGINAL_QUERY] and [CORRECTED_QUERY] as inputs. Parse the JSON response to extract semantic_drift_score (a float from 0.0 to 1.0) and intent_preserved (a boolean). Implement a threshold gate: if intent_preserved is false or semantic_drift_score exceeds your configured threshold (start with 0.3 and tune against eval data), route to a fallback path. The fallback should use the original uncorrected query for retrieval and log the correction as rejected. For high-stakes domains such as clinical or legal search, add a human review queue when the drift score falls in an ambiguous band (e.g., 0.2–0.5). Log every comparison with original_query, corrected_query, drift_score, intent_preserved, rationale, and the final query_used for audit and eval improvement.

Model choice matters here. This prompt requires strong semantic comparison ability, not just pattern matching. Use a capable instruction-following model such as gpt-4o, claude-3-5-sonnet, or an equivalent. Avoid using a tiny or local model for this gate unless you have calibrated its drift scores against a human-annotated dataset. Validation: after parsing the JSON response, confirm that semantic_drift_score is a number between 0 and 1 and that intent_preserved is a boolean. If the model returns malformed JSON, retry once with a stricter schema instruction; if it fails again, fail closed by using the original query and logging the error. Eval integration: maintain a golden dataset of original-corrected query pairs with human-labeled intent preservation judgments. Run this prompt against that dataset weekly, tracking the F1 score of the intent_preserved flag and the mean absolute error of the drift score. Set a monitoring alert if the agreement rate with human labels drops below 90%. What to avoid: do not use this prompt as the correction step itself—it is a verification gate, not a rewriter. Do not skip the threshold gate and blindly trust the corrected query; even high-confidence corrections can invert meaning on domain-specific terms. Do not log raw queries containing PII without redaction; if your system handles personal data, run a PII redaction step before logging the comparison payload.