fashion is a weird problem for computers.
there are millions of clothes.
millions of people.
billions of possible combinations.
and somehow, the hardest question is still:
“what should i wear?”
the obvious answer is to throw more intelligence at the problem.
bigger models.
bigger GPUs.
more data.
more compute.
but we think there is a better way.
don’t make the machine think harder. make the problem simpler.
that is the fundamental idea behind how we built polopan.
1. intelligence shouldn’t mean more compute
fashion is a huge computational problem.
- millions of products.
- millions of combinations.
- constantly changing inventory.
the obvious instinct is to throw more compute at it.
but more intelligence doesn’t always have to mean more computation.
if the same answer can be reached with a few CPU operations instead of running a large model again and again, why wouldn’t we?
that’s the principle behind PoloPan.
we do the expensive understanding once, when a product enters the system.
then we use a much lighter computational layer to reason over that understanding in real time.
the result isn’t just faster.
it’s a system that is far more efficient in how it uses compute – and far lighter on the hardware running it.
2. we separate “understanding” from “thinking”
this is the trick.
when a new product enters polopan, our neural models do the hard part.
- they look at the image.
- they understand the text.
- they identify things like silhouette, color, material, category, fit and aesthetic.
- they turn something messy and human into something a computer can understand.
in other words:
the neural network learns what the garment is.
and then we don’t need to keep asking the neural network the same question every time somebody opens the app.
we store that understanding → we compile it → and we build relationships between those things.
this creates our symbolic layer – a graph of items (looks → physical products)
3. understand once. use millions of times.
imagine teaching someone the rules of chess.
you don’t explain what every chess piece is every time they make a move.
you teach them once.
after that, the game is mostly about applying those rules.
we think fashion can work in a similar way.
when a new product enters polopan, our neural models do the difficult work:
- what is it?
- what does it look like?
- what kind of fit, colour, silhouette and aesthetic does it represent?
we turn that understanding into structured information.
then, when a user asks for an outfit, we don’t start understanding those products all over again.
we use what we already know.
that is the basic idea behind our neural → symbolic architecture.
the neural layer understands fashion.
the symbolic layer operates on that understanding.
these things go together.
these things don’t.
this look needs a bottom.
this product is unavailable in your size.
this alternative preserves the same style.
4. this changes what happens in real time
say there are 5 million products in the catalogue.
a traditional approach might repeatedly retrieve, score and rank huge numbers of candidates.
we do something different.
we represent constraints as extremely compact bitsets.
- price.
- size.
- brand.
- availability.
- category.
then the computer can perform simple operations on them.
₹2,000 AND size L AND Zara.
that’s not a philosophical question.
it’s a mathematical operation.
and modern CPUs are ridiculously good at mathematical operations.
our architecture is designed so that millions of products can be filtered through these operations extremely quickly.
the technical implementation uses sparse matrices and bitwise operations rather than dense transformer computation.
we don’t ask the AI to think about everything.
we make sure it only has to think about what matters.
5. but fashion isn’t just filtering
this is the important part.
if fashion were only:
“show me black shirts under ₹2,000”
we wouldn’t need to build any of this.
the interesting problem is:
“show me something that feels like me.”
that’s where the neural side comes back in.
your taste can be represented as a preference vector.
the system can find items that are aesthetically close to that preference.
but then the symbolic system can ask:
- is it actually shoppable?
- does it fit the constraints?
- does it belong in a complete look?
- what other items complete it?
the neural system gives us taste.
the symbolic system gives us logic.
together, they give us style intelligence.
6. the product is not the unit of intelligence
this is perhaps the most important architectural decision.
a product is just a physical instance.
a white linen shirt from brand A is one product.
a similar white linen shirt from brand B is another.
but the idea of the item can be the same.
and a look can exist independently of the exact product that happens to represent it.
so our system thinks in layers:
Look → Item → Product
a Look might require:
top + bottom + footwear.
an Item might represent:
minimal white linen shirt.
and Products are the actual things you can buy.
this means the intelligence doesn’t disappear when one SKU goes out of stock.
the product can change.
the underlying style relationship doesn’t have to.
7. this is why we call it neuro-symbolic
“neuro” handles the messy stuff.
- images.
- language.
- aesthetic perception.
“symbolic” handles the precise stuff.
- constraints.
- relationships.
- availability.
- combinations.
- logic.
it’s a very old idea in computer science:
use neural networks where ambiguity exists.
use deterministic systems where certainty exists.
we simply decided to apply that principle to fashion.
8. from products to a language of style
today, most fashion data looks like a database.
- SKU.
- price.
- brand.
- category.
- color.
- size.
- inventory.
useful stuff.
but that’s not how humans understand fashion.
we don’t say:
“i like product ID 847291.”
we say:
“i like this kind of look.”
that difference matters.
our goal is to turn the messy, subjective world of fashion into something machines can reason about.
not just:
what is this product?
but:
what does this product mean?
- what does it go with?
- what kind of person would like it?
- what look does it belong to?
- what can replace it?
- what happens when the price changes?
- what happens when the size disappears?
- what happens when the user changes their mind?
that’s the beginning of a Taste Graph.
9. the economics matter too
there is another reason we built it this way.
intelligence has a cost.
if every user request requires expensive model inference, personalization gets more expensive as you scale.
we wanted the opposite.
the more fashion we understand upfront, the cheaper it should become to reason over it.
our architecture moves the expensive perception work into the ingestion stage and keeps the real-time resolution layer predominantly CPU-based.
the result is a system designed around sparse computation rather than brute-force computation.
in our internal benchmarks, the symbolic inference layer targets sub-20ms latency and dramatically lower marginal inference cost than a pure LLM approach.
we’re not trying to win by buying more GPUs.
we’re trying to win by needing fewer of them.
10. the bigger idea
we don’t think the future of fashion is another bigger search box.
and we don’t think it is simply putting an LLM on top of a catalogue.
the interesting future is one where the computer understands the structure underneath fashion.
where a product is not just a product.
where an outfit is not just a collection of SKUs.
where taste is not just a list of things you’ve clicked.
where the system can understand:
if you like this, and this is your context, and this is your budget, then this is what makes sense.
that’s a different kind of recommendation.
it’s not predicting what you might click.
it’s computing what you can wear.
and that is what we’re building at polopan.
welcome to the taste graph.



