Can AI Really Understand What Products Belong Together?

An AI system does not show that it understands which products belong together merely by returning a plausible pair. A defensible ecommerce assistant evaluation asks four separate questions:

1. What relationship is the system claiming?
2. What evidence supports that claim?
3. Which facts- such as exact fit, required components, sellability, and current availability act as gates?
4. Can a merchant inspect, correct, suppress, and retest the result?

A similar item, a product often bought at the same time, a functional complement, a compatible part, a merchant-selected set, and a combination relevant to one shopper are different claims. They can overlap, but one does not automatically prove another.

For optional background on the surrounding discovery surfaces, see how recommendations work alongside search and filters.

The complete six-class taxonomy, evidence ordering, seven-row scorecard, four statuses, hard-stop rules, challenge cases, control contract, and evaluation sequence below are original editorial analysis informed by narrower platform documentation, academic research, independent UX research, and general AI risk guidance. They are not a standard, certification, benchmark, validated schema, universal model architecture, or description of a Wizzy product.

A plausible pair is not proof that products belong together

For this evaluation, “understanding” has a narrow operational meaning: the relationship claim is defensible for the recorded products or variants, market, context, and time after the relevant evidence and challenge checks have been applied.

Even that bounded pass does not establish human-like understanding. It does not certify an assistant, guarantee that a shopper wants the candidate, grade the system as a whole, or predict a commercial result.

The distinction matters because recommendation labels often compress several different decisions. Shopify, for example, documents related recommendations as similar or substitutable products and complementary recommendations as add-ons. It auto-generates related recommendations from sources such as sales data, product descriptions, and collection relationships, while complementary recommendations require manual configuration (Shopify recommendation intents; Shopify Storefront API). Those are Shopify-specific mechanics, not universal definitions or proof that any returned pair is correct.

Google’s Merchant API provides another bounded example: its product attributes include typed relationships such as required parts, accessories, substitutes, products often bought together, and parts of a set (Google ProductAttributes). A vocabulary can preserve useful distinctions, but a field or label does not prove that the source data is complete, current, or correctly applied.

A useful evaluation therefore follows this sequence:

name the relationship → trace the evidence → enforce hard gates and current state → challenge the claim → inspect the reason → retain merchant control

Use a non-numeric scorecard rather than a total. Mark each applicable row Pass, Fail, Unknown, or Not applicable, and record the evidence, owner, action, and retest trigger. A high number of passes must not cancel an incompatible exact variant or an unavailable required component.

Name the relationship before you evaluate it

Start by replacing the vague word “related” with the narrowest claim the evidence can support. The taxonomy below is an original evaluation aid; no reviewed source validates these six classes as a universal ontology.

Similar is an alternative, not automatically an add-on

Similarity answers a comparison question: could this other item serve a comparable job? It does not answer whether both products belong in the same basket. Independent UX research likewise separates alternative suggestions from supplementary ones because they serve different shopper purposes (Baymard on product-page suggestions).

Do not infer exact interchangeability from a shared category, similar image, nearby embedding, or matching description. Variant, specification, condition, seller, market, and ecosystem can all narrow the claim. “Alternative under these confirmed requirements” is more defensible than “equivalent.”

Co-purchase is an observation, not an explanation

“Frequently bought together” reports a behavioral association only when the underlying rule and dataset are defined. It does not explain why the items appeared together.

A survey of complementary recommendation research distinguishes similarity, buy-together patterns, use-together relationships, personalization, and cold-start concerns. It also notes that co-purchased items are not necessarily complements (complementary-recommendation survey). Peer-reviewed work on complementary recommendation similarly treats joint intention, co-purchase, similarity, asymmetry, and product diversity as distinct concerns (P-Companion paper).

Co-purchase can still help generate candidates or corroborate other evidence. The evaluation should ask for the event definition, scope, time window, market, exclusions, variant granularity, and known biases before accepting a broader label. Substitutes bought for comparison, household replenishment, gifts, and unrelated basket items can all produce plausible associations without proving joint use.

A complement supports a joint task but may not fit

A complement contributes to a coherent task or use case. That relationship can be directional: viewing a camera may justify suggesting a memory card, but viewing a memory card does not necessarily justify suggesting a camera. Academic work supports treating complementarity as more than simple similarity and recognizes that it can be asymmetric.

Complementarity remains broader than compatibility. A product category can be a sensible add-on without every item in it fitting the exact anchor. A style-coordinated item may be a subjective complement without any technical fit rule. Keep functional, aesthetic, replenishment, required-part, and optional-accessory claims distinguishable.

Compatibility is a hard claim at the exact variant level

Compatibility asks whether the exact items can work together under authoritative requirements. Independent UX research treats “related” as broader than “compatible” and describes compatibility databases as mapped relationships used for fit-dependent tasks (Baymard on compatibility databases).

Where incompatibility would make a suggestion unusable or unsafe, fit is a gate not a confidence boost. Require the relevant model, part, connector, voltage, dimensions, size, region, material, or other domain rule at the necessary granularity. Same brand, category, collection, or frequent co-purchase is not a substitute for missing compatibility evidence.

A product-level relation can also fail at the variant level. The parent product may be plausible while the selected size, model generation, voltage, connector, or bundle component is wrong. Unknown fit must remain unknown until verified; it cannot be presented as compatible because the pair looks convincing.

Curation, bundles, and personalization disclose different provenance

A merchant-curated pair says that a person or accountable team asserted the relationship. A fixed bundle says that products are offered together under defined component and offer records. Neither statement proves that an AI inferred the relation or that it was personalized.

Shopify’s documentation illustrates this distinction by requiring complementary recommendations to be configured manually while separately representing product variants and fixed-bundle components. That does not make the curation permanently correct. The evaluation still needs the exact variant, component availability, offer state, owner, and review time.

A shopper-specific combination adds another question: is this otherwise defensible relation useful for the current cart or requirement? Current explicit constraints should take precedence over unsupported historical inference. A previous click or purchase does not establish the present task, relax a compatibility rule, or justify duplicating an item already in the cart.

Ask what evidence authorizes the relationship

Different evidence sources are entitled to support different claims. The following order is original editorial analysis, not a universal ranking of data quality or a prescribed system architecture.

1. Authoritative hard facts and rules. Exact product and variant identity, part or model mappings, dimensions, interfaces, fit ranges, required components, bundle records, and current offer or availability state can act as gates. Their presence does not guarantee completeness, freshness, or use by the evaluated system.
2. Explicit merchant or domain assertions. Curated complements, substitutes, fixed sets, exclusions, and suppressions provide an accountable source. They should include an owner, reason, scope, and review time.
3. Catalog and content evidence. Titles, descriptions, categories, attributes, specifications, images, collections, and typed relations can support candidate generation, including for new products. They can also be missing, stale, copied, inconsistent, or attached only at parent-product level.
4. Behavioral evidence. Co-purchase, co-view, cart, search, click, and repeat-purchase patterns can support association or ranking. On their own, they do not establish function, fit, causality, need, or current preference.
5. Current shopper and cart context. A confirmed request, selected variant, cart contents, market, and explicit constraints can change whether a valid relation is useful now. They must not silently rewrite product facts or hard requirements.
6. A generated explanation or model score. This can make a proposed reason inspectable. It cannot upgrade weak evidence into a fact, replace a hard rule, or prove that fluent text faithfully reflects the model’s basis.

For each tested pair, ask the evaluated team or supplier to show:

• exact anchor and candidate product or variant identifiers;
• relationship label and direction;
• source type and an inspectable supporting record where available;
• applicable category, market, channel, and shopper or cart context;
• evidence owner, scope, granularity, last update, and known limitation;
• applicable compatibility rules and handling for missing evidence;
• publication, offer, inventory, and required-component state;
• shopper-facing label or reason and how it stays within the evidence;
• merchant review, suppression, replacement, rollback, and correction path; and
• monitoring and retest triggers after material data, rule, model, inventory, bundle, or context changes.

The wording shown to a shopper should preserve provenance. “Customers also bought” describes observed behavior. “Merchant-selected set” describes curation. “Compatible with model X under rule Y” describes a bounded product fact. A generic phrase such as “perfect match” can overstate all three.

Run seven checks without hiding hard failures in a total

Apply the scorecard to one anchor item or confirmed cart plus one candidate at an exact product or variant, market, channel, and time snapshot. For every row, record the status, evidence, limitation, challenge case, owner, action, and retest trigger.

• Pass: Evidence supports the row for the tested pair, context, and time.
• Fail: Evidence contradicts the claim or an applicable required condition.
• Unknown: Necessary evidence is absent, stale, conflicting, or not inspectable.
• Not applicable: The row genuinely does not apply, with the reason recorded.

Do not total, average, weight, or convert these statuses into a percentage. An applicable compatibility or current-state Fail is a stop for the tested candidate. An Unknown hard requirement calls for verification, clarification, a conditional response, or no candidate not an optimistic pass.

Current state deserves its own gate because relationship validity and present sellability are different questions. Shopify’s merchant documentation, for example, applies product status, publication, price, cart, and inventory requirements to displayed recommendations, including a stock requirement for complementary products (Shopify recommendation requirements). That rule is specific to Shopify. It demonstrates why an otherwise valid relationship can still be ineligible now; it does not establish a universal inventory policy or freshness guarantee.

Use challenge cases that make plausible mistakes visible

A polished demo can hide the cases that matter most. Exercise the scorecard against positive, negative, stale, sparse, and regression scenarios. The cases below are generic, hypothetical editorial tests—not observed products, merchants, customers, recommendations, failure rates, or benchmarks.

Build the evaluation set around the categories and risks that matter to the merchant. Include representative high-volume items, long-tail or new products, hard- and soft-compatibility cases, merchant-curated relations, shopper-specific combinations, inventory changes, and cases where no safe candidate exists.

No reviewed source supplies a universal sample size, class balance, pass rate, threshold, cadence, or launch rule. A real test set must reflect category risk, catalog change, and merchant operations. Passing these hypothetical families would not measure accuracy or predict production performance.

Make merchant review and override part of the evaluation

A recommendation can be plausible today and wrong after a catalog, inventory, bundle, rule, model, or context change. Evaluation therefore needs a correction and retest loop, not just an initial output review.

Require a bounded, inspectable reason

The reason should identify the relationship label and its evidence basis where available. It should also preserve scope: the exact anchor and candidate, direction, market, channel, context, and time. Missing fit, stale inventory, or conflicting records should remain visible.

An explanation is not proof of correctness or faithfulness. If the only evidence is co-purchase, the system should not claim that the products were designed to work together. If an authoritative mapping supports exact compatibility, the explanation can state that bounded fact while keeping shopper need and current availability separate.

Give correction an owner and a reversible control

Ask whether an accountable merchant-side owner can approve, suppress, replace, or override the relationship. Record what changed, why it changed, which products or relationship classes are affected, and how the previous state can be restored.

Shopify documents manual recommendation selection, display choices, and suppression controls in one platform. General NIST AI Risk Management Framework guidance separately supports documentation, contextual evaluation, human oversight, feedback, monitoring, appeal or override, and change management (NIST AI RMF Core). Neither source prescribes this commerce-specific control contract or proves that a particular interface is effective.

Where shopper context is involved, keep a way to reject or revise the inferred context. That is an evaluation control, not legal advice or a complete privacy program.

Test whether the correction survives change

A correction that disappears after a refresh is not a durable control. Add the bad pair or failure pattern to regression cases, then retest after material changes to catalog records, relationship data, business rules, models, inventory, bundles, policies, or context handling.

Also preserve Unknown and no-safe-candidate outcomes. A system should be able to stop, ask a useful question, condition its wording, or return no candidate rather than manufacture certainty.

Decide what a pass means and what it does not

Use this original practical sequence to turn the scorecard into a bounded buying or governance decision:

1. Define the intended relationship classes, categories, shopper contexts, and unacceptable failure types.
2. Select representative and challenge cases, including long-tail or cold-start items and current-state changes.
3. Freeze the exact products or variants, market, channel, context, source evidence, and timestamp.
4. Run every applicable scorecard row with evidence, limitation, owner, action, and retest trigger.
5. Treat applicable compatibility and current-state failures as stops; keep missing hard evidence Unknown.
6. Review risk-sensitive cases with the accountable catalog, domain, merchandising, product, or governance owner in the reader’s organization.
7. Test shopper-facing labels and explanations against the actual evidence.
8. Verify suppression, replacement, rollback, and persistence of merchant corrections.
9. Retest after material changes.
10. Record the decision as bounded to the tested relationship and conditions, never as a universal system grade.

A defensible ecommerce assistant evaluation does not ask whether an AI can produce a convincing pair. It asks whether the relationship is named precisely, the supporting evidence is inspectable, applicable compatibility and current-state gates survive challenge cases, and a human can correct the result.

Under that narrow definition, a system can make a defensible product-relationship claim. It still has not proven that it understands products as a person would, certified its overall recommendation quality, or predicted what shoppers will buy. The useful outcome of the evaluation is more modest: a relationship claim whose scope, evidence, unknowns, controls, and retest conditions are visible.