An AI stylist should argue, not decree

A recommender system, in the form most of us meet it, is a ranked list with the reasons hidden. It works for a film: you either watch it or you do not, and the cost of a bad pick is an evening. It works, more or less, for a song. Clothes are different in a way that matters to the design. You are the one who will stand in the outfit, in front of people, in weather, for a whole day, and you know things about the day that no model does. A verdict without reasons asks for a kind of trust that no system has earned, and it leaves you nothing to push back on when it is wrong — which, on any given Tuesday, it will be.

So the interface I wanted for ZIMRICS’s Stylist is closer to a colleague than an oracle. Today’s Pick composes an outfit in steps — the dress, then the footwear, then the jewellery and accessories — and each step says why: the forecast, the occasion on the calendar, how much walking is in the day, what has been worn recently and what has been neglected. You are choosing between reasons, not accepting a result. Any step can be reshuffled, and a reshuffle is itself a signal the system learns from: not that the navy was wrong, but that on days like this, with reasons like these, you prefer the grey.

This is not a soft preference about tone. Explanations change what a system optimises. A model that must justify a pick in terms a person recognises — “the navy, because the meeting is formal and you wore the grey on Tuesday” — is constrained to reason over features that actually matter, rather than over whatever correlations in the training data happened to score well. The explanation is a specification. It rules out a whole class of recommendations that would be statistically defensible and practically absurd, and it does so without anyone having to enumerate them.

It is worth being concrete about what an argument from the Stylist looks like, because the word can sound grander than the thing. A morning pick might read: the green dress, because it has not been worn in three weeks and the calendar shows a lunch; the flat sandals rather than the heels, because the forecast is dry and the day has two kilometres of walking in it; the gold rather than the silver, because the dress measures warm and the gold sits closer to it in colour space. Three sentences, each tied to a fact the wearer can check and a preference she can override. That is the whole interface, and it is more than most recommenders offer about anything.

It also changes what the system is allowed to know, which is where my other job comes in. To argue from the weather it needs the forecast; to argue from the occasion it needs the calendar; to argue from wear history it needs the log; to argue from colour it needs the measurements. Each of those is a permission, and each should be visible as one. In ZIMRICS they are settings with plain-language reasons attached — this switch lets the stylist read your calendar, and here is what it does with it — because a system that reasons over your data should be able to say which data, and should let you take it away and keep working, worse but honestly, without it. A recommender that quietly degrades when you withhold a permission is telling you something true about what it was using.

There is a modest version of the choice-overload research underneath all of this. Iyengar and Lepper’s jam study found that twenty-four options drew a crowd and sold to three percent of it, while six options sold to thirty. A wardrobe of forty tops is a large jam table; a stylist that returns a ranked list of forty outfits has only moved the table onto a screen. What actually reduces the load is one composed answer with its reasons attached and a cheap way to say “not that — the other shoes”. Fewer decisions, each of them informed, each of them yours.

There is also a plain engineering reason to prefer explanation, which anyone who has debugged a recommender will recognise. A system that can only output a ranking can only be tested by whether people accept the ranking, which conflates a dozen causes — the weather was wrong, the calendar was stale, the colour measurement was off, the wearer was in a mood. A system that outputs reasons can be tested reason by reason: the forecast it used can be checked against the forecast that was true, the wear history it cited against the log. When it is wrong, you can see which premise was wrong, fix that premise, and know the fix worked. An oracle cannot be debugged. A colleague can be corrected.

The failure mode to design against is the opposite one, and it is seductive: the stylist that is always right. A system tuned to maximise acceptance will learn to recommend what you already wear, because that is what you will accept, and it will slowly narrow your wardrobe to the five things you reach for anyway. That is not styling. It is a mirror with a delay. A stylist that argues can do the thing a good human stylist does — propose the piece you had forgotten, and tell you why today is the day for it — because it is not afraid of the reshuffle. The reshuffle is the conversation.

A word on what “AI” should mean in this context, because the term has come to promise more than it delivers. Composing an outfit from what you own is a constrained search over a small, well-described space, guided by a handful of features that can be named. It does not need a model that has read the internet. It needs your garments as data, your day as data, and a scoring function you can read. The intelligence, such as it is, lies in the constraints being right and the reasons being honest — and a system like that can run on the phone, with your wardrobe never leaving it, which is how it should be.

The test I hold the product to is simple, and I would offer it as a test for any recommender that touches something personal. If the Stylist cannot say why, it should not say what. A pick you cannot interrogate is a horoscope with a wardrobe attached, and I did not build it to tell fortunes.