The Outfit Engine Said No to Everything, and Three of My Sites Were Lying to Google

Here’s what actually happened -- with enough context, I hope, that it makes sense whether or not you’ve ever written a line of code.

I’ve been building an app that looks at your closet and suggests outfits from what you actually own. This week, every single request to it failed with a “400” -- a “400” is a status code, the web’s universal way of saying “I don’t understand what you’re asking me for.”

The cause was two lines in the rulebook I’d written for the AI -- the technical term is a “schema,” basically a contract that says “your answer has to look like this.” Two of the rules I’d written in that contract weren’t rules the AI’s tool actually supports. So the request was getting rejected before the AI even tried to answer -- it wasn’t giving a bad answer, it was never getting the chance to answer at all. Fixed the contract, and left a note next to the fix so I don’t make the same mistake twice, because a matching mistake was already sitting quietly in a second spot in the code.

Once it actually ran, the suggestions were still off. Every outfit came back wrapped in the same overshirt, and it never once suggested shorts -- despite owning several since spring. Turned out I’d only been telling the AI about clothes I already owned, so a category with nothing in it (like, apparently, “shorts I forgot I told it about”) was invisible to it -- it couldn’t suggest what it didn’t know existed as a category. Told it about every possible category, owned or not. Fixed itself in one line.

And then the mistake that’s really on me: I had a rule that said “always add a third layer” -- a jacket, a cardigan, something on top. I’d justified it with a real statistic: fewer than five out of about forty reference photos showed an outfit with nothing layered over it. Sounds rigorous.

The math was right. The conclusion was wrong, because I never asked whether the sample matched the question. Layers are optional now, and mostly a cold-weather thing.

The pattern underneath all of it, if there is one: a build succeeded and showed a green “it worked” message, while the actual result sat unchanged just below it -- so it *looked* broken even though it wasn’t. Being correct and being obviously correct turned out to be two different jobs, and I’d only been doing the first one.

Separately, I went through four websites I run and found the same failure shape on three of them, in different clothes each time.

jbmangum.com -- hadn’t published anything new since March. I found the local project files gone; I’d deleted them myself, on purpose, and then forgot I had. Nothing was actually lost. The history was safely in git the whole time but the real discovery was that every single deploy attempt since March had been silently failing in the background. The site just kept showing whatever the last successful version was, for months, with nothing anywhere telling me it had stopped updating. Fixed the pipeline. This blog now pulls straight from Substack the moment I hit publish, instead of waiting on a rebuild step that could fail without telling anyone -- again.

Crown & Compasshad the clearest version of the pattern: visiting a page that didn’t exist quietly served the homepage instead, and told the visitor’s browser everything was fine (a “200,” the status code for success). To a search engine, a site that says “success” for pages that don’t exist looks like it has infinite duplicate content. Fixed -- broken links now correctly say “not found.”

Record Store Directory had the same bug on six of its seven record-detail pages: a missing record redirected to a list instead of saying “not found.” One page had it right the whole time. Copied its logic to the other six.

Ascend Systems, my software company, was the one exception -- zero problems found there this round, which is its own kind of good news after a redirect fix from a few weeks back turned out to actually hold up.

Three different sites, three different flavors of the same mistake: telling a visitor (or a search engine) “everything’s fine” when it very much was not. That failure mode doesn’t show up as an error anywhere, because as far as the server’s concerned, nothing went wrong. It’s the software equivalent of nodding along to a question you didn’t hear.

If there’s one thing both halves of this week have in common, it’s that: the data was right, the code ran, and nobody -- me, a search engine, a user staring at a screen -- was actually told the truth about it. Worth checking on the quiet parts more than I do.