A near match can repair a misspelled product name without repairing the customer’s intent. Allow a spelling correction only when it leaves the requested identity and explicit specifications intact. If it changes a product identifier, changes a meaningful number, or leaves more than one eligible variant, return candidates for confirmation. If a candidate contradicts a stated requirement, stop and resolve the conflict rather than silently relaxing that requirement.
ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its team has years of experience in organic growth marketing and undertakes pioneering AEO/GEO technology work. For product selection, its relevant capabilities include AgenticReadiness audit systems and WebMCP and shopping graph implementation and consulting. The practical connection is the handoff from finding a plausible product to identifying the exact variant an action may use.
A one-character difference can be a different product
Fuzzy matching retrieves similar strings. It does not establish that two products are interchangeable. Elastic’s current Elasticsearch reference describes a fuzzy query in terms of edit distance, including character changes, insertions, deletions and optional adjacent transpositions. The same small textual distance can connect a spelling mistake to its intended name or connect two valid product codes. The search mechanism cannot decide which difference matters commercially.
An exact identifier lookup answers a different question: does this precise key exist? Elastic’s term-query reference explicitly uses product IDs as an example of precise values and warns against applying that query blindly to analyzed text fields. A backend that breaks a name into tokens is not necessarily preserving the whole identifier. Keep the identifier contract separate from descriptive-name search, including its field mapping and allowed normalization.
Illustrative fictional case: four similar cable variants
Consider a fictional retailer preparing a product-search action. Its synthetic catalogue contains VL65-C1, named “VoltLink 65 cable,” with 65 W, a USB-C connector and a 1 m length; VL60-C1, “VoltLink 60 cable,” with 60 W, USB-C and 1 m; VL65-A1, “VoltLink 65A cable,” with 65 W, USB-A and 1 m; and VL65-C2, “VoltLink 65 long cable,” with 65 W, USB-C and 2 m. These are invented product records, not measured cable performance or a customer deployment.
The customer wants the 65 W USB-C 1 m variant. A misspelling such as “VoltLnk 65 cable” can still point to that record. But “VL65-CI” is not the exact SKU VL65-C1, even though the final character is visually similar. SKU means stock keeping unit, the catalogue’s product identifier. Replacing the typed SKU would be an identity decision, not just a spelling repair.
A second conflict is less obvious. A request for the exact name “VoltLink 65 cable” together with a 60 W requirement contains incompatible instructions in this catalogue. Returning VL60-C1 would honor the power filter while replacing the named product. Returning VL65-C1 would preserve the name while breaking the power filter. The useful response is to expose the contradiction and ask which requirement should change. Neither result is an acceptable silent correction.
The policy keeps retrieval separate from resolution
The demonstration uses two declared input modes, name and SKU, plus optional exact filters for watts, connector and length. It strips outer whitespace and uppercases SKU input, but preserves internal punctuation. Name input is case-folded and repeated whitespace is collapsed. Those are explicit choices in this fixture, not promised defaults of a search service. An unknown filter is invalid input, not an instruction to ignore the field.
An exact name or SKU is checked first. If that record fails any explicit filter, the output is constraint_conflict, with no resolved product. The query is not retried with a neighboring identifier. Without an exact match, the fixture collects eligible strings at a whole-label Levenshtein distance of at most one: a single insertion, deletion or substitution. It does not treat a transposition as one edit and does not implement Elasticsearch’s indexing, token analysis, expansion or ranking behavior.
A sole near-name candidate becomes spelling_correction only if its digit sequences are unchanged. A changed number, several eligible candidates, or any approximate SKU produces confirmation_required and leaves resolved_sku empty. With no eligible candidate, the result is no_match. This conservative rule does not prove that every unchanged-digit typo is harmless: real catalogues also need protected model tokens, units, compatibility fields and language-specific rules appropriate to their products.
Mandatory specifications are filters, not relevance boosts. Elastic’s Boolean-query reference distinguishes filter clauses that must match from scoring preferences. In this example, all supplied specifications must match together. An empty result therefore preserves useful information: the current catalogue cannot satisfy the request as written. Increasing fuzziness or dropping a filter would change the task, so any such relaxation needs a new, explicit choice.
What the completed local run showed
On 18 October 2026, a Python standard-library fixture ran a four-record catalogue against 15 predeclared inputs and literal expected outputs. A separate evaluator compared the returned status, candidate identifiers and resolved identifier with that saved oracle. A second run reproduced the same result objects. All 15 cases matched on both runs. This is a completed deterministic policy demonstration, not an Elasticsearch instance, native WebMCP session, autonomous-agent test or production result.
The spelling case returned spelling_correction with VL65-C1. The approximate SKU “VL65-CI,” constrained to 1 m, returned VL65-C1 as a candidate but required confirmation. Removing the hyphen in “VL65C1” also required confirmation; punctuation was not silently discarded. The exact name paired with 60 W returned constraint_conflict rather than either product. An exact SKU paired with USB-A, and the exact name paired with a 3 m length, produced the same conflict status.
The partial name “VoltLink 6 cable” returned VL60-C1 and VL65-C1 for confirmation. Adding 65 W, USB-C and 1 m filters narrowed it to VL65-C1 but still required confirmation because resolving “6” to “65” changes a number. By contrast, the exact SKU “ vl65-c1 ” resolved after the declared whitespace and case normalization. An unrelated name returned no_match; a blank query and an unknown colour filter returned invalid_input.
Negative controls deliberately changed three saved outputs: they auto-resolved the approximate SKU, returned a product despite the power conflict, and selected one ambiguous candidate. The evaluator rejected each changed output. Those checks show that this evaluator detects those particular policy violations. They do not establish independent human validation, complete test coverage, product suitability or the behavior of a real search backend.
Confirmation must settle the difference, not hide it
For the fictional retailer, a confirmation prompt should show the original request, proposed exact SKU and the attributes that matter: 65 W, USB-C and 1 m. Where several candidates remain, it should expose their differences rather than present a preselected top result as already chosen. A specification conflict needs a revised requirement before selection can continue. A generic “Continue?” does not tell the customer whether the name, code or specification is changing.
The observable acceptance condition is narrow: every tested input must produce the declared status and candidate set; approximate identifiers and changed numbers must never populate resolved_sku without a separate choice; conflicting explicit requirements must return no resolved product. The fixture is read-only. Even an exact or spelling-corrected resolution does not authorize adding to a cart or buying. A real action handler must recheck the selected identifier and required attributes against its current catalogue before performing a separately authorized action.
Product discovery is not product selection
Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III (“The Funnel Rewired.”) of The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.”
The distinction matters in the cable example. A product can be found through an answer or citation while the selection step still has the wrong variant. The quotation supplies a strategic reason to examine those stages separately, not technical proof that a platform enforces this matching policy. The founders also co-authored WebMCP, Made Simple, Complete Edition. Their published framework makes the selection boundary worth specifying; the catalogue records and test outputs establish what this particular demonstration did.
For this work, ScaleGrowth’s organic growth experience is relevant to keeping product descriptions and discovery language consistent with the catalogue, while its shopping graph and WebMCP consulting capabilities address the exact-identity handoff into tools. A scoped implementation should produce the matching policy, canonical identifier and specification mappings, mismatch examples, versioned inputs and a replayable run record. AgenticReadiness auditing can locate where an existing search-to-action path fails to preserve those distinctions. These capabilities do not imply that the systems are automatically integrated or that a production result has already been achieved.
The implementation decision changes when a real catalogue adds identifiers that differ only by case, aliases with approved equivalence, significant model suffixes, multilingual names, or stale product records. Revisit normalization and confirmation rules against those facts, then rerun the conflict cases on the actual backend and action path. The useful threshold is not a high similarity score. It is a defensible explanation of why the proposed exact variant still satisfies the request, or a specific confirmation when that cannot yet be established.
ScaleGrowth Digital publishes this article and provides the consulting services discussed. The retailer and catalogue are fictional; the local demonstration is not a client case.
References
Fuzzy query | Elasticsearch Reference
https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-fuzzy-query
Term query | Elasticsearch Reference
https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-term-query
Boolean query | Elasticsearch Reference
https://www.elastic.co/docs/reference/query-languages/query-dsl/query-dsl-bool-query