Support and catalog search acceptance workshop / 6 MIN READ
Keep a near-match product code from masquerading as an exact result
A synthetic code-query contract with exact code, one-character neighbor, shortened prefix and ordinary language controls, including explicit non-exact result labeling.
AI-assisted research and analysis for the SNS Creative Fieldbook
Sources checked 2026-11-07
A near-match code can describe a different product, not a helpful spelling correction. Accept identifier lookup separately from ordinary discovery language while keeping both useful in the same search experience.
What you will leave with: A synthetic code-query contract with exact code, one-character neighbor, shortened prefix and ordinary language controls, including explicit non-exact result labeling.
Use this when
- Product-code searches can return neighboring or partial identifiers.
- Identifier precision must coexist with ordinary descriptive discovery.
Not separate typo/prefix tuning lessons, synonym expansion or evidence that two parts are physically interchangeable.
Declare which values carry identity
Algolia documents separate attribute-level controls for typo tolerance and prefix matching, checked 7 November 2026. Their searchable-attribute requirements differ. Disabling one behavior does not establish a complete exact-identity guarantee across tokenization, punctuation, case handling or synonyms. Inspect the actual search path rather than treating two switches as a universal solution.
Ask the catalog owner which fields are identifiers and which are descriptive language. A model code, part number and marketing nickname may look similar in a spreadsheet but have different matching contracts. Record the consequence of substituting a neighboring identifier. Where product compatibility is involved, qualified evidence determines suitability; search similarity cannot provide that evidence.
Create positive and negative query pairs
Use synthetic identifiers with deliberately close neighbors. Include the full intended code, a one-character difference, a shortened prefix and a natural-language query that should still support discovery. Define the expected response for each: confirmed identifier match, clearly labeled alternatives, or no confirmed match. Do not require every query to produce a purchasable result.
Add a formatting variation only if the catalog owner says it preserves identity. A separator may be cosmetic for one identifier scheme and meaningful for another. Record that rule rather than normalizing all punctuation indiscriminately. The fixture should preserve the line between an accepted representation of the same identifier and a genuinely different identifier that happens to look similar.
Trace the field that caused the match
For each query, inspect which indexed attributes and transformations contributed to the result where the implementation exposes that evidence. A correct identifier field can coexist with a descriptive field that mentions several neighboring codes. The resulting item may be useful for discovery without qualifying as an exact code match. Keep those interpretations separate in the result presentation.
Test the complete route, including suggestions and the results page if both can make an identity claim. A suggestion that presents a neighboring code as the queried item can fail even when the full results page labels it correctly. Verify the destination’s identifier and selected configuration. Do not turn off useful language-search behavior everywhere merely to fix one identifier field; the requirement is a deliberate boundary, not universally rigid search.
Accept an honest fallback for uncertain identity
The result contract should state when the system can claim an exact identifier match and what it does otherwise. Alternatives should preserve their actual codes and explain that they are alternatives rather than silently rewriting the request. For consequential parts, an unresolved code should lead to the approved verification route, not a confident compatibility suggestion.
Retain the positive, neighbor, prefix and language fixtures together. A change that improves discovery can weaken identifier precision, while a strict identifier repair can make ordinary language search unnecessarily brittle. Review both before accepting the change. The artifact is one combined precision contract, with no production setting changes and no claim that search matching establishes physical interchangeability.
Make the reasoning concrete.
A fictional supplier stocks two components with synthetic codes differing by one character. A search for the unavailable code returns the other component as if it were an exact match, while staff celebrate the reduced empty-result rate.
Treat every result as a repair
Opening: Accept the near neighbor because the query no longer returns nothing.
Hypothesis: The search dashboard looks healthier.
Risk: A different identifier can be mistaken for the requested component.
Separate identity from discovery
Opening: Require a confirmed-code path and label any other result as an alternative.
Hypothesis: The shopper can distinguish an exact match from a suggestion.
Risk: Some queries must remain unresolved pending proper verification.
The supplier keeps the two identifiers distinct and tests ordinary language queries alongside the stricter code fixture. It does not infer compatibility or broaden a product claim from the search engine’s similarity score.
Take the questions into your next brief.
Use these prompts in your own notes. Nothing is submitted from this page.
Identifier
Which field and formatting rules define identity?
Neighbors
Which synthetic near codes must remain different?
Transformations
Which matching behaviors contribute to the result?
Presentation
How are non-exact alternatives labeled?
Regression
Do precision and ordinary discovery both survive the change?
Watch for the wrong conclusion.
- Calling every fuzzy result an exact identifier match.
- Assuming disabling typos also disables prefixes and other transformations.
- Using search similarity as evidence of physical compatibility.
Your next action
Create one full-code, neighboring-code, prefix and language-query fixture set and define the identity claim each may support.
Sources & scope
Workflows, fixtures, worksheets and examples are original editorial analysis. Sources support the narrow attributed statements, not measured business results. Platform guidance is scoped to the documented implementation and date checked. Synthetic acceptance only; no external changes, messages, index operations or permissions are performed.
- disableTypoToleranceOnAttributes →Primary platform documentation · Supports: Supports attribute-level typo control only; the separate prefix reference supports its own scope. The combined precision fixture and non-exact presentation contract are original.
- disablePrefixOnAttributes →Primary platform API parameter reference · Supports: Documents separate attribute-level prefix control and its searchable-attribute requirements; it does not establish universal exact identity.