How xplo thinks about fashion discovery.
A working document describing the principles, methodology, and evaluation practices behind xplo's product discovery engine. Written for engineers, product leaders, and investors who want to understand why discovery is structurally broken on most ecommerce sites — and what we’re doing about it.
Overview
01 · primerxplo is a product discovery engine for fashion. It addresses two concrete user intents that today’s keyword search and filter panels handle poorly, if at all:
Visual Search
The shopper describes a feeling, occasion, aesthetic, or brief — in their own words — and receives a ranked set of items. “A slip dress for a summer gallery opening.” “Something quiet-luxury for a second date.”
Visual Browse
The shopper starts from an item and steers the result in natural language. “Like this, but more country.” “This silhouette in a muted palette.” Refinement happens in prose, not in a facet panel.
Both modes sit on a shared pipeline that parses natural-language intent into a structured design specification, grounds it against a vision-indexed catalog, and returns an auditable result. The rest of this document describes that pipeline at the level of principle, not implementation.
Taxonomy values and controlled vocabularies — the closed axes, the palette family names, the aesthetic cluster labels — are the product. They do not appear here and will not in future revisions. Evaluation apparatus — test libraries, query sets, ground-truth annotations — is partially openable under a protocol described in §10; today it is held back, and that is a position we expect to revisit. Methodology — the shape of the taxonomy, how the parser behaves on edge cases, the QA escalation logic, the planned-vs-actual principle — is what this document is for, and we intend to publish more of it, not less.
When we reference “the planner,” “the vision tagger,” or “the controlled library,” we are describing roles in a pipeline, not products we invite you to reproduce.
The discovery gap
02 · primerThe defining fact of the last decade of ecommerce is that catalogs grew faster than the tools to navigate them. Online fashion is a $872B market in 2025, projected to reach $2.18T by 2034 at a 10.7% CAGR (DataIntelo, 2025). The infrastructure built to let shoppers find anything in that market is, on most sites, demonstrably broken.
The most rigorous public benchmark is Baymard Institute’s work on ecommerce product lists. Across 327 top sites, 4,400+ test sessions, and more than 200,000 hours of UX research, they report the following (Baymard Institute, Ecommerce Product Lists & Filtering, ongoing research program):
On-site search tells the same story from the other side. Across multiple UX studies, 15–43% of ecommerce visitors use site search, and those visitors generate a disproportionate share of revenue — in common findings, roughly 45% of revenue comes from the ~15% of visitors who search (Findbar, eCommerce Site Search Statistics Report, 2026; AddSearch, 2026). Yet up to 25% of searches in large catalogs return zero results, and 20–45% of sessions require at least one refinement after a poor initial result (NewMedia, 100+ E-commerce Site Search Statistics for 2026).
Fashion is harder than Baymard’s average. The attributes that matter — silhouette, aesthetic, occasion, formality, mood — are subjective, overlapping, and poorly served by faceted filters. Our working hypothesis: the numbers above understate the fashion case.
Search modes
03 · primerxplo distinguishes two retrieval modes because the shopper’s starting point is fundamentally different in each. Collapsing them into one “AI search” surface — as many vendors do — loses information.
Visual Search — intent-first
The shopper begins with a description and no reference item. The query can be a mood (“quiet-luxury”), an occasion (“gallery opening”), a scenario (“second date, not trying too hard”), or a mix. The system’s job is to parse that prose into a structured design specification rich enough to retrieve against, without forcing the shopper to translate intent into facet values.
Visual Browse — item-first
The shopper starts from a specific item they like and wants to explore the neighborhood around it. Unlike “more like this” recommendations, xplo accepts a natural-language steering instruction: “like this, but more country,” “same silhouette, muted palette,” “dressier version of this.” The system treats the instruction as a transformation applied to the source item’s specification, then retrieves.
The two modes share the same underlying representation of a garment — the structured design specification — which makes it possible to move between them mid-session. A Visual Search result can become the anchor for a Visual Browse refinement, and vice versa.
Intent parsing
04 · methodologyMost ecommerce search treats the query as a bag of words. Keyword-matching engines try to align tokens with product text. Embedding-based semantic search projects the query into a vector and finds neighbors. Both approaches share a weakness: they operate on the query as written, not on what the shopper is asking for.
xplo parses natural-language queries into a structured design specification — an intermediate representation that names the dimensions of the request explicitly. Silhouette, pattern behavior, palette intent, formality range, aesthetic cluster, motif character, cultural references, and so on. Not all fields are populated for every query; vague briefs produce specifications with deliberate ambiguity preserved.
Why a structured intermediate
- It preserves dimensions that raw embedding similarity collapses (a floral dress is not close to a non-floral dress just because their silhouettes match).
- It makes refinement possible as a structured edit — the core of Visual Browse.
- It makes retrieval auditable: we can point at the dimensions that drove each result.
- It lets us separately diagnose failures of understanding from failures of retrieval.
Vague briefs are not errors
The parser is designed to treat vagueness as information, not as a problem to resolve. A brief like “something for Sunday” underspecifies deliberately, and a healthy parser produces a specification with open dimensions rather than guessing. When the parser feels forced to guess, we treat that as a bug in the parser, not a limit of the shopper.
Ambiguous briefs return multiple candidates
Some briefs are not merely vague — they have more than one coherent reading. “A country-style shirt for a lumberjack in Alaska” invites at least two: a literal workwear interpretation (flannel, buffalo check) and a themed country-&-western one (embroidered western-cut, rose motifs). The parser returns both rather than collapsing to a median compromise; retrieval ranks across candidates and the shopper picks. See figure 4.1.
Three retrieval modes beneath the two product surfaces
Visual Search and Visual Browse are the two product surfaces (§03). Underneath, the structured spec supports three distinct retrieval operations — three ways the same catalog can be queried against the same vocabulary. A query resolves into one or more of these:
- Hard categorical match. Closed-axis values (silhouette, palette family, pattern structure) match by equality. A garment either belongs to the column silhouette cluster or it doesn’t. No gradient, no fuzz.
- Soft weighted mixture. Multi-value axes (aesthetic, cultural reference, mood) match by position-weighted affiliation. A garment tagged
[y2k, mcbling, maximalist]is 45% a y2k match, 25% mcbling, 18% maximalist — it shows up in all three result sets, strongest first. Tag position is the retrieval-ranking signal. - Continuous scalar comparison. Numerical scales (formality, length, looseness, structure, and a dozen others) match by distance. “More formal than this one, same length” is a legal query; the system walks the scale in the requested direction.
Every shopper-facing query resolves into some combination of the three. A prose brief to Visual Search might invoke all three (the cultural tag soft-matches, the silhouette hard-matches, the formality scalar-matches). Visual Browse refinement (“like this, but more country”) is typically a soft-mixture edit. The three modes are compositional.
Vision grounding
05 · methodologyA structured specification is only useful if the catalog has been described in the same vocabulary. xplo indexes imagery through a vision pass that produces a parallel structured description of each item — its actual attributes, as observed from the photograph, rather than as claimed by merchandiser metadata.
This matters because merchandiser-supplied attributes are frequently wrong, missing, or inconsistent across suppliers. A vision pass anchored in the same taxonomy as the parser normalizes the catalog independent of its source.
Master reference method
Vision models drift. The same image, described twice by the same model, often produces subtly different tags — enough to degrade retrieval at scale. xplo’s vision pass uses a master reference methodology: all images are described against a shared anchor that constrains lighting, framing, and presentation assumptions. The anchor is versioned; updating it is treated as a catalog-wide re-indexing event, not a silent change.
What we deliberately do not do
Fashion taxonomy
06 · methodologyxplo’s retrieval sits on a controlled, multi-axis fashion taxonomy. Unlike hierarchical category trees (the standard in merchandising PIMs), the xplo taxonomy is orthogonal by design: every garment is described simultaneously along several independent axes.
Controlled vocabulary, free-form semantics
The axes above are closed — values are drawn from a controlled list. Alongside them, xplo accepts free-form fields for cultural references, associative tags, and named motifs. This hybrid is intentional: the closed axes make retrieval consistent; the open fields keep the language of fashion — which is irreducibly cultural — from being over-compressed.
Shape of the taxonomy
We are comfortable describing the shape of the vocabulary even though we don’t publish its values. The shape is useful to anyone evaluating whether a taxonomy-grounded retrieval system is likely to work in their category; the values only matter to someone trying to copy ours. Concrete numbers, in ranges:
Admissibility and governance
New closed-axis values are not added ad hoc. A proposed value has to satisfy three tests: it names a distinction that at least one real shopper query rests on; it is visually grounded (a vision pass can reliably recognize it); and it does not collapse into an existing value under test-library evaluation. Values that fail any of the three stay as free-form tags — which is where most of the “aesthetic” and “cultural” vocabulary actually lives, by design.
Deprecations follow the reverse path: a closed value whose test-library retrieval consistently disagrees with shopper intent is reviewed, and either refined into narrower values or demoted to free-form. Taxonomy edits are versioned and logged; an edit that changes closed-axis membership is treated as a catalog re-indexing event, not a silent change.
One garment, many axes
To make the orthogonality concrete: a single item lights up several closed axes simultaneously, and typically several free-form ones. The figure below shows one real catalog item rendered along its axes. The values shown are this garment’s values; they are not the axes’ vocabularies.
A resolved disagreement
Nothing signals real research like visible trade-offs, so one that was argued out: we debated whether aesthetic should be modeled as a single dominant value or permitted to carry multiple tags per garment. The single-value reading is cleaner for retrieval, but it collapses cases like the one in Figure 6.1, where a garden-party shirt-dress is legitimately cottagecore, preppy, heritage, and light-academia at once. Forcing a single dominant value loses the cross-cluster matches a shopper’s query often needs — “preppy but softer” requires the garment to be indexed as both. We landed on multi-value aesthetic with weighted dominance, on the condition that every value carries a test-library query that would retrieve the garment on that value alone.
A related case: whether workwear belongs on the aesthetic axis or the formality axis. We argued for months. The resolution was to split it: “workwear” as an aesthetic cluster (visual language — chore coats, canvas, utility hardware) separate from “work-appropriate” on formality. The two often co-occur but are not the same claim, and collapsing them was producing retrievals where a utility jumpsuit was surfaced for “business casual” queries.
Threat model — what we protect, and why
“We don’t publish X” is a cheap thing to write, and in most industry research pages it carries no weight. What follows is the concrete reasoning, kept short so it can be argued with.
- What we protect. The closed values on each axis (silhouettes, pattern structures, aesthetic clusters, palette families), the admissibility rules that govern them, and the query-to-spec mappings that retrieval depends on.
- What we are protecting against. Two specific failures. First, downstream consumers using the vocabulary as a drop-in without the evaluation discipline that produced it — the vocabulary is only as good as the test libraries that keep it honest, and copying one without the other is a trap. Second, adversarial optimization against the axes: if a retailer knows the closed values, prompt text and product copy drift toward them, and the index becomes a mirror of the vocabulary rather than a description of the catalog.
- What publishing enables that we judge to be safe. Cardinality of each axis, admissibility rules, governance cadence, resolved design disagreements, single-item worked examples (see below), and aggregate benchmark results.
- What would move the line. If a shared industry benchmark emerges and requires vocabulary disclosure for comparability, we open the closed axes and accept the adversarial-optimization cost. That trade is not on offer today because no such benchmark exists.
A versioned, living object
Fashion is not static. The taxonomy is versioned, reviewed on a cadence, and updated as categories emerge or shift. Changes are logged in the changelog, with compatibility notes describing how prior indexes are migrated or re-computed.
Palette extraction
07 · methodologyColor is the attribute most ecommerce systems get wrong, and color is the attribute shoppers most often use to express taste. Resolving this gap is disproportionately important to retrieval quality, and deserves its own methodological section.
Why we do not trust vision models for color
Vision models are competent at describing what a color looks like in words (“dusty terracotta,” “washed navy”) but are unreliable at reporting hex values, relative coverage, or role (primary, accent, trim). Across internal tests, vision-reported hex values drift by double-digit percentages relative to pixel ground truth, and coverage estimates are often qualitative at best.
Mechanical extraction, semantic labeling
xplo’s palette pipeline splits the work:
- Mechanical step. Background is isolated, dominant color clusters are extracted pixel-wise with coverage percentages, and negligible clusters are discarded.
- Semantic step. The resulting clusters — exact hex, exact coverage — are then passed to a language model for role labeling and family assignment within the controlled palette vocabulary.
This is a small idea with an outsized effect. It means “show me dresses in the color family of this item” is a retrievable query with a correct answer, not a vibe.
Quality control
08 · methodologyxplo operates a two-stage quality control process on every item that enters the index. The stages are ordered deliberately: mechanical checks run first, because they are cheap, deterministic, and unambiguous; semantic checks run second, because they handle questions mechanical tests cannot.
Stage 1 — mechanical
Objective properties that can be measured directly from pixels: background purity, image dimensions, aspect ratio, compression artifacts, color-cast indicators. Stage-1 failures are automatic; the item is routed to review without the semantic stage being run.
Stage 2 — semantic
Subjective properties that require judgment: does the image represent the described garment faithfully? Is the ghost-mannequin or on-model presentation coherent? Are there out-of-domain artifacts (text, logos, watermarks)? Stage-2 checks are run only on items that passed stage 1.
Retry and escalation
Failed items are retried with a bounded budget and, if they fail repeatedly, written to a review queue rather than silently dropped. Drop rates, retry rates, and queue sizes are tracked and published in aggregate.
Auditability
09 · methodologyWhen a retrieval result is bad, the question “why?” has two possible answers, and systems that conflate them cannot be debugged. Either the system misunderstood the shopper (a parsing failure), or the system understood correctly but retrieved the wrong items (an indexing or matching failure). xplo treats these as separate diagnostic surfaces.
This split — planned vs actual — is the organizing principle of xplo’s debugging and evaluation. Every retrieval stores both sides. Quality regressions can be attributed. Prompt changes can be tested without regenerating the index. Index changes can be tested without re-parsing historical queries.
Consequences for product surface
- Result explanations (“why this item?”) are grounded in the structured spec, not post-hoc.
- Visual Browse refinement operates on the spec; it is a structured edit, not a new query.
- A/B tests can isolate parser changes from index changes — rare in the category.
Benchmarks
10 · evaluationSearch quality claims in the ecommerce industry are, with rare exceptions, unfalsifiable. “AI-powered” and “semantic” and “understands natural language” are not testable statements. xplo’s evaluation practice is built on the opposite commitment: every capability claim must be measured against a fixed, curated test set with published protocol.
Controlled test libraries
We maintain purpose-built test libraries — curated sets of items and queries designed to exercise specific dimensions of retrieval (aesthetic cluster ambiguity, palette nuance, silhouette vs pattern precedence, cultural reference handling). Each library has a fixed ground truth and a versioned protocol. Regressions on any library trigger review.
What we publish
- Aggregate precision and recall on each library, by query class.
- Parser disagreement rates (the same brief, parsed twice, same spec?).
- Vision tagger stability (the same image, described twice, same tags?).
- Retrieval attributability (what share of results can we explain dimension-by-dimension?).
What we do not publish
- The libraries themselves.
- The exact query sets.
- Implementation-level scores that would be gameable out of context.
Partners and auditors may be granted access under NDA. We expect, in time, to propose a shared industry benchmark for fashion retrieval — along the lines of what Baymard did for product-list UX. That work is not yet public.
Position papers
11 · libraryLonger-form writing from Alt9Lab, organized by theme. Drafts and forthcoming pieces are listed without dates.
- draft Filters were always a compromise: a brief history of faceted navigation, 2001–2026.
- forthcoming Planned vs actual: auditable retrieval as a design principle. — the case for treating query-side and index-side failures as separately measurable; extends §09.
References
11b · libraryExternal sources cited above. This list is maintained as new data is added to the methodology sections.
Market sizing
- DataIntelo. Online Fashion Retail Market — Research Report 2034. 2025. dataintelo.com/report/online-fashion-retail-market
- UniformMarket. Ecommerce Fashion Insights and Trends (2025 Data). 2025. uniformmarket.com/statistics/ecommerce-fashion-insights-trends
- McKinsey & Company and Business of Fashion. The State of Fashion 2026. 2025. mckinsey.com/industries/retail/our-insights/state-of-fashion
Discovery, filters, and product-list UX
- Baymard Institute. Ecommerce Product Lists & Filtering — UX Benchmark. 327-site benchmark across 70 weighted guidelines; 4,400+ test sessions; 200,000+ hours of UX research. baymard.com/research/ecommerce-product-lists
On-site search behavior
- Findbar. eCommerce Site Search Statistics (2026 Report). 2026. findbar.io/ecommerce-site-search-statistics-2026-report
- NewMedia. 100+ E-commerce Site Search Statistics for 2026. 2026. newmedia.com/blog/ecommerce-site-search-statistics
- AddSearch. On-Site Search Statistics for Ecommerce and Others. Updated 2026. addsearch.com/blog/site-search-statistics
- Segmentify. 30+ On-Site Search & Discovery Statistics. 2023, updated 2026. segmentify.com/blog/on-site-search-discovery-statistics
- Opensend. 13 On-Site Search Conversion Rate Statistics for eCommerce Stores. 2025. opensend.com/post/on-site-search-conversion-rate-statistics-ecommerce
Visual search & adoption
- Envive. 30 Visual Search Conversion Statistics for Ecommerce. 2026. envive.ai/post/visual-search-conversion-statistics
- Vecstore. Visual Search Is Changing How People Shop Online. 2026. vecstore.app/blog/visual-search-ecommerce
- Imagga. Visual Search and the New Rules of Retail Discovery in 2026. 2025. imagga.com/blog/visual-search-and-the-new-rules-of-retail-discovery-in-2026
- Invesp. The State of Visual Search — Statistics and Trends. Updated 2026. invespcro.com/blog/the-state-of-visual-search
- Pixyle. The Essential Guide to Visual Search in Fashion Ecommerce. Updated 2026. pixyle.ai/guides/the-essential-guide-to-visual-search
- Lee, J., et al. Linking Assortment Variety, Search Costs, and Experiential Benefits in Fashion Visual Search. Clothing and Textiles Research Journal. 2025. journals.sagepub.com/doi/10.1177/0887302X251341495
Adjacent prior art
- IBM Research. Cognitive Fashion — AI for Fashion API reference. A prior taxonomy-grounded approach to fashion-specific visual and text search; a useful reference point for what’s been tried. cognitivefashion.github.io/slate
Changelog
12 · libraryPublic record of methodology revisions, taxonomy updates, and benchmark protocol changes. Implementation-level changes are not logged here.
- 2026 · 04 v0.2 — three-bucket publication stance, taxonomy shape disclosure, threat model, single-item worked example (Fig 6.1).
- 2026 · 04 v0.2 — research site published.