Why Fashion Recommendation Engines Don't Create Outfits (Co-Purchase vs Similarity vs Coordination)

In short: Most fashion recommendation systems answer one of two questions, and neither one builds an outfit. Frequently-bought-together runs on co-purchase data, which finds items that sell in the same basket but are usually not meant to be worn together. "You may also like" runs on similarity, which finds items that resemble each other, the opposite of what an outfit needs. Building an outfit is a third problem, coordination: reasoning about whether pieces of different categories work together. Co-purchase and similarity are not coordination in disguise, and the difference decides what a "complete the look" widget can actually do for your store.

Question the system answers	What it runs on	Good at	Why it fails at outfits
What gets bought with this?	Co-purchase data (order history)	Surfacing proven basket pairings	Co-purchased items are rarely meant to be worn together; blind to new and slow inventory
What looks like this?	Similarity (feature/visual nearest-neighbours)	Finding interchangeable substitutes	An outfit needs different categories that relate, not the same item repeated
What completes this to wear?	Coordination (cross-category compatibility)	Building a wearable look	This is the actual outfit problem, and it needs a system built for it

Open almost any fashion product page and scroll to the recommendations. You are looking at a black kurta. The carousel shows you four more black kurtas. Helpful, in a way, if what you wanted was to compare kurtas. Useless if what you wanted was to know what to wear with the one you already like.

Scroll to the other widget, the one that says customers also bought. Now you get a phone case, a pair of socks, and a kurta in a different size. Also not an outfit.

This is not a quirk of one store's setup. It is what the underlying systems are built to do, and most of them are built to do one of two things, neither of which is building an outfit. Understanding the difference is the whole game, so it is worth being precise about it.

Three different questions that look like one

When a system recommends a product, it is answering a question. There are three questions worth separating, because almost every recommendation engine answers the first or the second while fashion shoppers are asking the third.

The first question is what gets bought alongside this? That is frequently-bought-together, and it runs on co-purchase data: the engine looks at orders, finds items that show up in the same basket often, and surfaces them. The second question is what is similar to this? That is the "you may also like" carousel, and it runs on similarity: the engine represents each product as a set of features and finds the nearest neighbours. The third question is what completes this into something I can wear? That is coordination, and it is a different problem with a different answer.

The trap is that all three produce a row of product images under a thing you are looking at, so they look identical in the interface. They are not identical underneath. The first two are solving problems that are adjacent to outfitting and are routinely mistaken for it.

Why co-purchase is not coordination

Co-purchase data is seductive because it is cheap and abundant. Every store already has order history, so finding items that sell together costs nothing extra. The problem is what co-occurrence in a basket actually means.

The team at ASOS, which has one of the larger styling operations in fashion ecommerce, put it plainly when they built their own outfit dataset. They deliberately did not use co-purchase data, and explained why: co-purchase is not a strong signal of compatibility, because co-purchased items are typically not bought with the intention of being worn together. A basket is more likely to reflect a shopper's overall taste than a single outfit. Someone buying three unrelated tops in their preferred colour palette generates three co-purchase links, none of which is an outfit.

It gets worse in exactly the cases where styling matters most. Co-purchase data is thin or missing for new products, for slow movers, and for any pairing a shopper has not already discovered on their own, which is the entire point of a recommendation. If the data only knows what people already buy together, it can never suggest the pairing nobody tried yet. It is a rear-view mirror sold as headlights.

Why similarity is the opposite of coordination

The similarity carousel has a deeper problem, and it is almost philosophical. Similarity and coordination are not just different, they pull in opposite directions.

Think about what makes two products similar: same category, same colour, same cut, same vibe. Now think about what makes an outfit: a top and a bottom and shoes that are emphatically not the same category, that relate to each other without matching. A recommender tuned to find things like the kurta will surface more kurtas, because more kurtas is the correct answer to "what is similar." It is the wrong answer to "what goes with this."

This is not a hand-wave. It is a known, named distinction in the computer-vision research on fashion. The most-cited paper on the problem, Vasileva and colleagues at ECCV 2018, draws the line exactly: a system for building outfits has to learn two separate notions, similarity (when two tops are interchangeable) and compatibility (items of possibly different type that go together in an outfit). The two are different enough that the researchers had to learn them in different mathematical spaces, because forcing them into one space breaks.

The way it breaks is worth understanding, because it explains the black-kurta carousel directly. In a naive single-similarity setup, everything that matches a given top is pushed close to that top in the model's representation. But then every shoe that works with the top is also forced close to every other shoe that works with it, and close to the top, and the whole space collapses toward "things that resemble each other." Similarity is roughly transitive: if A looks like B and B looks like C, then A looks like C. Compatibility is not. A scarf can complete two different outfits that have nothing to do with each other. The math that is good at similarity is structurally bad at compatibility, which is why a similarity engine pointed at an outfit problem returns more of the same item.

The research framing makes the same point from the retrieval side. A survey of the field separates fashion retrieval, which learns visual similarity between items of the same type, from fashion recommendation, which has to learn compatibility between items of different types. Different task, different machinery. Bolting a "complete the look" label onto a similarity engine does not change which task it is doing.

What coordination actually requires

So what is the third thing? Coordination is reasoning across categories about whether pieces work together: a top with a bottom, a bottom with footwear, the whole set against an occasion. A team at Target, working on exactly this, described outfit completion as going beyond the traditional problem of visual similarity, because it requires modelling compatibility relations across different categories and across multiple factors at once, colour, material, pattern, texture, and shape. That is a different and harder computation than either nearest-neighbour similarity or basket co-occurrence, and it is the one that produces an actual outfit.

This is where the gap between paradigms gets wider in Indian fashion, not narrower. Co-purchase data does not understand that a Bandhani dupatta and a solid kurta coordinate through contrast, or that print-on-print can work when the palettes agree and fail when they fight. Similarity does not understand that the right pairing for a saree is a blouse that relates to it rather than repeats it. And neither understands occasion, the single most load-bearing variable in how Indian shoppers actually assemble looks. A system trained on what already sold, or on what looks alike, is blind to the reasoning a stylist does in two seconds.

Complete the Look is a coordination problem

Plenty of fashion brands add a "Complete the Look" widget expecting it to assemble outfits on its own. Whether it does comes down entirely to what powers it, and the label on the widget tells you nothing about that.

A Complete the Look widget running on co-purchase data will show what sold together, which is the frequently-bought-together problem wearing a different name. One running on similarity will show products that resemble the item already on screen, which is the "you may also like" carousel wearing the same disguise. Both are product recommendations dressed up as outfit recommendations. Only a coordination-based system actually tries to answer the question a shopper has in mind on a product page: what completes this look.

This is the distinction that separates real outfit merchandising from a generic recommendation feature with a fashion label. AI merchandising for fashion is not one capability; it is whichever of the three problems the underlying system was built to solve. If you are evaluating a complete-the-look or outfit-recommendation tool, the question to ask the vendor is not whether it does outfits, but what it reasons about: co-purchase, similarity, or compatibility.

Why this matters for what you put on your store

None of this is academic if you sell clothes. It decides what your recommendation widget can and cannot do for you.

If your "complete the look" feature is powered by co-purchase data, it is showing shoppers what they already figured out how to buy together, which is the smallest possible win and worthless for new or slow inventory. If it is powered by similarity, it is showing more of the item they are already looking at, which competes with the sale instead of growing the basket. Either way you are paying for a widget that answers a question your shopper is not asking.

The question they are asking is what to wear with this. Answering it well is a coordination problem, and a coordination problem needs a system built to reason about compatibility across categories, not one repurposed from co-purchase logs or a similarity index. That distinction is the entire reason this gets done properly or not at all.

Frequently asked questions

Can frequently-bought-together create outfits? Not reliably. Frequently-bought-together runs on co-purchase data, which finds items that appear in the same orders. Those items are usually not bought to be worn together, so the pairings reflect a shopper's overall taste rather than a coordinated look. It is also blind to new and slow-moving products, which have little or no co-purchase history.

What is the difference between similarity and compatibility in fashion AI? Similarity measures how alike two items are, which is useful for finding substitutes, like one top that can replace another. Compatibility measures whether items of different categories work together in an outfit, like a top with a particular bottom and shoes. Fashion-AI research treats them as separate problems that require separate models, because a system tuned for similarity returns more of the same item rather than the pieces that complete it.

Why don't product recommendations work for fashion? Most recommendation engines are built to answer "what is similar to this" or "what sells alongside this." A fashion shopper on a product page is asking "what do I wear with this," which is a coordination problem. Engines repurposed from similarity indexes or co-purchase logs are not built for coordination, so their suggestions either repeat the item or surface unrelated products.

What is coordination in outfit recommendation? Coordination is reasoning across categories about whether pieces work together: a top with a bottom, a bottom with footwear, and the whole set against an occasion. It accounts for colour, pattern, material, and silhouette at the same time. It is a different and harder computation than nearest-neighbour similarity or basket co-occurrence, and it is the one that produces a wearable outfit.

Does a "complete the look" widget guarantee real outfits? No. The label says nothing about what powers it. A "complete the look" widget built on co-purchase data or similarity carries the same limitations as those methods. What matters is whether the system underneath reasons about cross-category compatibility, not the name on the widget.

Full disclosure: Angadi is our product, and this is the problem it is built to solve. It reasons about coordination, top to bottom to footwear to occasion, and the brand approves every look before it goes live, so nothing publishes that you would not have styled yourself. We are not the only way to solve a coordination problem. We are just clear that coordination is the actual problem, and that co-purchase and similarity are not it in disguise.