- A maintenance buyer has already found a product that will do the job.
- The price is too high, the preferred supplier has no stock or the finish is wrong.
- Those requests depend on a reference product.
- For a B2B marketplace built with Medusa and Elasticsearch, we made product-equivalent discovery explicitly anchored.
The client problem
A maintenance buyer has already found a product that will do the job.
The price is too high, the preferred supplier has no stock or the finish is wrong. The buyer does not want to start a new search with a retail product name. They want to say: “show me an equivalent”, “same thing but stainless” or “something like this under $100”.
Those requests depend on a reference product. If an AI assistant invents that reference—or quietly switches to a different SKU—the rest of the recommendation can look convincing while answering the wrong question.
For a B2B marketplace built with Medusa and Elasticsearch, we made product-equivalent discovery explicitly anchored. The product page supplies a trusted SKU and product context. The language model may interpret how the buyer wants the alternative to differ, but it cannot replace the anchor with one of its own.
The marketplace then resolves the real catalogue record, searches for viable candidates and applies commercial rules such as access, stock, effective price and supplier diversity.
The buyer gets alternatives to the product they actually selected—not alternatives to a product the model imagined.
“More like this” is incomplete without “this”
Conversational search contains references that make sense to a person looking at a screen.
“This one”, “the same”, “a cheaper version” and “but in stainless steel” all rely on the current product page. The text alone does not contain a SKU, category, price or specifications.
A generic search assistant may try to reconstruct the product from conversation history or its own wording. That creates a hidden ambiguity. If the inferred reference is wrong, every later filter is applied coherently to the wrong item.
The planner context therefore carries an anchor supplied by the application: SKU, title, price, category names and selected specifications. It also knows whether the question came from a product page or a general search bar.
That context turns anaphora into an auditable input. “Cheaper than this” has a known price. “Same but stainless” has a known set of current attributes. “Find an equivalent” has a product identity that can be resolved against the catalogue.
Bind the plan to the trusted SKU after the model responds
The model is asked for a structured retrieval plan, not the final product list.
One allowed retrieval mode is similar. That mode requires an anchorSku. The model schema permits only the SKU already present in context—or no anchor at all.
The backend adds a second boundary. After the provider returns its proposed plan, deterministic binding overwrites the plan's anchor with the trusted context SKU. A test deliberately supplies a hallucinated SKU from the model and verifies that the accepted plan retains the trusted one.
If no anchor exists, validation drops the similar retriever and falls back to a normal hybrid search path. The system does not manufacture a reference merely to keep the conversational experience moving.
This is a small but powerful rule: the model may decide that the user's request means “find similar products”; the application decides which product “similar” refers to.
Resolve the authoritative catalogue copy
A SKU can appear in several denormalised search documents or supplier contexts.
The recommendation route resolves the authoritative source record for the anchor before building candidate queries. From that document it derives product name, price, category, supplier, specifications, manufacturer, numeric attributes, product type and finish when present.
This prevents the retrieval layer from treating the buyer's screen label as sufficient truth. The SKU leads back to the indexed product representation the marketplace uses for search and availability.
The route then excludes the current product and near-duplicate copies from recommendations so the carousel does not answer “find an alternative” with the same item from the same supplier at approximately the same price.
The public promise remains appropriately bounded: the search is grounded in the catalogue record attached to the trusted SKU. It is not a claim that every supplier dataset contains perfect specification coverage.
Separate what must stay the same from what may change
Product equivalence is not one universal score.
For an appliance part, type words and dimensional specifications may be essential. For a whole appliance, product subtype, capacity and finish may matter. For a sparse catalogue item, the name can carry more useful identity than missing attributes.
The route derives several signals from the anchor: decision specifications, numeric fields, text specifications, product type, name-type tokens, manufacturer, finish and category subtype. It can also identify specifications that discriminate within the category.
Hard-filter and fallback passes use those signals with different strictness. The first pass preserves strong constraints. Later passes can relax preferences when the initial set is too small, while retaining semantic boundaries such as a recognised type signature where available.
This is not a promise of perfect functional equivalence. It is a transparent retrieval strategy that starts from observable catalogue attributes instead of a free-form language-model judgement.
Let the buyer state the intended difference
Many useful equivalent searches are differential.
The buyer wants the same type but a different finish, a lower price or another supplier. The planner can use anchor context to translate that request into explicit filters rather than losing it inside a rewritten search sentence.
For “cheaper than this one”, the anchor's actual price supplies the ceiling. For “same but stainless”, a validated specification value can override the corresponding anchor preference. Explicit URL filters already selected by the buyer retain priority over model-proposed values.
The plan supports price, specifications, stock, pickup, distance, delivery speed, brand, manufacturer, vendor and category controls. Proposed catalogue values are checked against live vocabularies; unsupported constraints are dropped instead of being smuggled into search text.
The buyer's requested difference becomes visible and testable. The rest of the product identity continues to come from the anchor.
Keep commercial access rules after AI interpretation
Similarity cannot override what the buyer is allowed to buy.
Before querying recommendations, the route resolves the marketplace access context used by the normal product surface: country and property geography, excluded products and vendors, allowed vendors and shopping-list restrictions. Vendor price lists are also resolved for effective-price decisions.
Those constraints are applied to the candidate query independently of the conversational planner. A strong specification match from an excluded seller is still excluded. A product outside the buyer's catalogue perimeter does not become visible because the model called it equivalent.
This is crucial in B2B commerce, where assortment and negotiated supplier relationships are part of the product experience. “Best alternative” means best among the options this organisation can legitimately purchase.
AI changes how intent enters the pipeline. It does not grant a second route around catalogue governance.
Rank stock before elegance
An alternative is useful only if the buyer can act on it.
The recommendation candidates are mapped with stock context, and in-stock products rank ahead of out-of-stock products. Within that boundary, the route considers discriminating-spec matches, high overall specification match, finish, number of matching attributes, relevant name-token overlap, manufacturer tie-breaks and Elasticsearch score.
When the buyer requests price ordering, the candidate set remains gated by strong similarity signals before effective price sorts the useful alternatives. Negotiated price-list overrides can contribute to the price the buyer actually sees rather than relying only on a standard catalogue value.
This makes the ranking serve procurement. A nominally close product that cannot be purchased today should not automatically outrank an available, well-matched substitute.
The ordering is an implemented decision system; it does not by itself prove improved buyer conversion or universal recommendation accuracy.
Preserve supplier choice in the result set
A recommendation list can be technically diverse and commercially repetitive.
If the highest-scoring products all come from one supplier, the buyer may not see a viable alternative from another approved source. The route therefore limits the initial number of products per supplier. If that rule leaves the result set too short, it relaxes the cap gradually rather than returning an empty or undersized list.
This balances two goals: surface cross-vendor choice where the catalogue supports it, and still fill the recommendation set when only one supplier carries the category.
Supplier diversity is applied after access and relevance, not as a reason to inject unrelated products. It is a presentation and commercial-choice rule over the eligible candidates.
The buyer can compare meaningful alternatives instead of scrolling through several near-identical offers from one source.
Return the comparison, not only the products
An equivalent list is easier to trust when the interface explains the difference.
For each recommendation, the route compares specifications with the anchor and can attach price and shipping comparisons. Matching, different and unique attributes become part of the response. The current product is also returned as the explicit reference.
This lets a product card say more than “recommended”. It can show that width and capacity match, finish differs, price is lower or delivery context changes.
The buyer remains responsible for deciding whether the substitute is appropriate for the job. The platform reduces the comparison effort and keeps the reference visible.
Explainability here is practical, not philosophical. The user can see which catalogue facts caused two products to look alike and which important facts changed.
Evaluate the contract with difficult language
Anchored search needs tests that reflect how people actually speak.
The query-plan suite includes cases such as “more like this”, anchored multilingual requests, price-relative alternatives and differential specification changes. It checks trusted-anchor binding, missing-anchor fallback, maximum-price derivation and accepted structured plans.
The recommendation route has focused request tests for anchor parameter handling, and the wider planner tests protect catalogue truth, explicit filter priority and invalid-plan fallback.
These tests demonstrate the intended behaviour of the fixed repository state. They do not prove production satisfaction or a particular relevance percentage.
Their value is that the product promise becomes executable: similar retrieval requires an anchor, the anchor comes from context, and buyer constraints remain structured.
Why Medusa was the right foundation
Medusa supplied the product, price and availability lifecycle. Elasticsearch supplied the read-optimised catalogue surface. The client needed a procurement search experience that could extend those foundations without creating a second, AI-owned catalogue truth.
We placed the planner before retrieval and mapped its accepted controls back into governed product routes. The recommendation endpoint resolves real Medusa catalogue identities, effective prices and marketplace access before returning alternatives.
This architecture lets the interface become conversational while the commerce engine continues to own purchasability. The model interprets “same but cheaper”; the platform decides which SKU is “this”, which products exist and which ones the buyer may order.
An extensible commerce system makes that division possible without reducing AI search to a disconnected chatbot.
A practical anchored-search checklist
Before offering “find an equivalent”, define:
- Which application surface supplies the anchor?
- Is the anchor a stable SKU or a model-generated phrase?
- Can the backend overwrite a hallucinated model anchor?
- What happens when no trusted anchor exists?
- How is the authoritative catalogue record resolved?
- Is the current product excluded from its own alternatives?
- Which attributes are identity constraints for the category?
- Which preferences may be relaxed during fallback?
- How does the buyer express one intended difference?
- Do explicit buyer filters outrank model proposals?
- Are proposed catalogue values validated against live vocabulary?
- Do access, stock and negotiated-price rules still apply?
- How are sparse product records handled?
- Does supplier diversity preserve relevance?
- Can the interface explain matched and changed attributes?
- Which behavioural cases protect the anchor contract?
The anchor is the beginning of trustworthy similarity, not a minor parameter.
The broader lesson
“Find something like this” should never require the buyer to redescribe a product the platform already knows.
For this marketplace, the product page contributes a trusted SKU and commercial context. The planner identifies a similar-product intent and any requested difference. Deterministic binding prevents the model from changing the reference. Elasticsearch retrieves candidates from the actual catalogue, while access, stock, effective price and supplier-choice rules determine what is useful to show.
The final response keeps the original product and the comparison visible.
That creates a better division of labour. Language is good at understanding “same, but cheaper”. The commerce system is responsible for knowing what “same” starts from, which alternatives exist and whether this buyer can actually purchase them.