Query correction

Problem Context

• The product accepts free-form submitted queries over a large content set.
• Search relevance can compute likely spelling, phrase, split, join, or token corrections.
• Some queries contain names, identifiers, codes, acronyms, legal references, or domain terms that must not be overcorrected.

Selection Rules

• Choose query correction when correction happens after an explicit search submission, not while the user is merely typing.
• Auto-apply a correction only when the corrected query is high confidence and returns useful results; otherwise show a did-you-mean candidate.
• Always show the original query and provide a direct search-original path when corrected results are displayed.
• Highlight only the changed query tokens or phrases, not every result card, so users can understand what changed.
• Clear or recompute correction state when the user edits the query, changes scope, changes language, or submits again.
• Treat fuzzy matching, synonym expansion, semantic matching, token dropping, and query correction as separate behaviors unless the changed text is explicitly disclosed.
• Avoid correction, reduce tolerance, or require confirmation for codes, SKUs, usernames, product numbers, acronyms, quoted exact phrases, numeric tokens, names, legal terms, medical terms, and domain vocabulary.
• Use no-results recovery rather than query correction when spelling is valid but filters, scope, availability, permissions, or empty data caused the zero-result state.
• Use search suggestions when the user needs help forming a future query before submission; use autocomplete when the user must select a constrained known value.
• Localize correction behavior by language, keyboard, script, stemming, plural rules, and domain vocabulary instead of assuming one global dictionary.

Required States

• No correction state when the submitted query is exact or correction confidence is too weak.
• Auto-applied correction state showing corrected results, original query, changed tokens, and search-original action.
• Did-you-mean state showing one or more correction candidates that have not yet been applied.
• Original-query state after the user chooses to search the submitted wording instead of the corrected wording.
• Edited-query state where stale corrections clear and the new submitted query drives the result count.
• Exact-token state where identifiers, codes, quoted phrases, or configured words bypass correction.
• No-results-with-correction state where a correction is offered alongside normal empty-result recovery.

Interaction Contract

• Submitting a query records the submitted text separately from any corrected query used for results.
• If corrected results are shown, the result summary states which corrected query is active and offers a reversible action to search the original.
• Choosing Search instead for original reruns or reveals results for the original submitted text without changing the user's typed history into the correction.
• Accepting a did-you-mean candidate applies that candidate as the active corrected query and updates the result count.
• Editing or clearing the search field invalidates stale correction metadata until the next explicit submit.
• Correction candidates must be bounded, ranked, and deduplicated so users are not asked to choose from noisy spelling variants.
• Exact-match and sensitive-token rules must be applied before automatic correction changes user intent.

Implementation Checklist

• Store submittedQuery, correctedQuery, correctionStatus, confidence, changedTokens, and originalResultCount as distinct state fields.
• Define confidence thresholds for auto-applied correction, did-you-mean suggestion, and no-correction fallback.
• Configure dictionaries, exact words, disabled attributes, numeric-token rules, language analyzers, and domain-specific exceptions before launch.
• Display correction copy in the result summary and keep the search field behavior consistent with whether the user is editing original or corrected text.
• Provide Search original, Accept correction, edit query, and clear correction actions where relevant.
• Log overcorrection events, search-original usage, accepted corrections, no-click corrected results, and zero-result typo queries for relevance tuning.
• Test misspellings, transpositions, missing letters, extra letters, split words, joined words, plural forms, names, acronyms, identifiers, quoted phrases, multiple languages, mobile typos, and stale-response races.
• Keep correction independent from autocomplete suggestions, saved searches, recent searches, highlighting, and no-results recovery actions in the data model.

Common Generated-UI Mistakes

• Silently replacing the user's query without saying what changed.
• Treating every fuzzy or semantic match as a corrected query.
• Correcting identifiers, names, acronyms, product codes, or quoted terms that users intended to search exactly.
• Showing only zero results for obvious typos when a strong correction exists.
• Keeping a correction active after the user edits the query or changes scope.
• Labelling pre-submit suggestions as did-you-mean corrections.
• Hiding no-results recovery because a low-confidence correction candidate exists.
• Displaying too many correction candidates with no ranking or explanation.

Critique Questions

• Can users see both the original submitted query and the corrected query?
• Is the correction auto-applied only when confidence and result quality justify it?
• Can users search the original wording, accept a candidate, edit the query, and clear stale correction state?
• Which tokens, fields, languages, codes, acronyms, names, numbers, or quoted phrases bypass correction?
• Does the interface distinguish correction from autocomplete, search suggestions, synonym expansion, fuzzy matching, and no-results recovery?
• What telemetry will reveal overcorrection, false positives, and ignored correction suggestions?