The data model already knew
The expensive part of your AI product is already built. Your interface is throwing it away.
Early in an engagement with an analyst platform, before I could touch code, I was reading the engineering team’s own architecture diagram for their assistant workflow. On the right side there were two boxes, clearly labeled. One was context verification: select the relevant locations and times, prune what comes back. The other was context expansion: go find more data when there isn’t enough. Both were crossed out.
The post-search intelligence layer. Drawn by engineering. Then removed from scope.
Someone had sketched the knowing and then deleted it.
A few weeks later I had a development environment and traced the backend pipeline myself. The interrupt machinery, the system’s ability to pause mid-run and say I need more from you before I proceed, already existed as a status in the workflow. Built. Sitting there. Nothing in the interface ever rendered it.
That’s when it became a thesis instead of an observation. I wasn’t going to be inventing capability. I was going to be surfacing it.
When results landed, the data model was holding everything a filter needs. Every item carried its source, its provider, its geometry, its capture time. It had already resolved the query’s scope, the locations and times pulled from what the person typed, held as structured objects. So when a person reached for something simple, show me just this provider, narrow this to last week, everything required to honor it was sitting in state.
The interface couldn’t do it. Its mental model was: a query is an event, results are a printout, change means start over. When leadership ran the product on a real task and wrote up where it broke, every snag was the same gap wearing a different outfit. Some of those paths actually existed. The team could walk you through them. They just weren’t discoverable. The product was hiding its own capability. Hard to blame the person for that.
So I started taking inventory. Structured interrogation of the repo: here’s the design intent, here are five questions, give me file and line references. And for every gap, tell me whether it’s tractable in the frontend with data already returned, or whether it needs new backend work. That one lens sorts everything into polish layer versus real scope. It kept me honest about what was built versus what I was imagining.
The finds kept coming. A field reserved for a histogram nobody had designed yet. A provenance link tying every image back to the query that produced it, which is a navigation system waiting to happen. A single flag that decided whether results streamed in as they arrived or got held until the whole run finished, meaning the loading experience was one flag away from being a different product. Citations that existed in the data, waiting to be verified and wired to a click. And that interrupt status, a whole human-in-the-loop mechanism the interface never used.
None of it was hidden. It just wasn’t anyone’s job to see it as experience.
I think the reason is mostly sequence. AI-native products get built model-first, because that’s where the existential risk lives. The pipeline, the retrieval, the state, all of it exists before design does. Engineers can see what’s coming, so they leave hooks: reserved fields, provenance links, status enums. Rendering those hooks is nobody’s job. Then caution compounds it. When streaming feels risky, you hold everything until the run finishes. When density looks messy, you cap what renders. Each choice is locally sensible. Each one makes the interface dumber than the system behind it.
When design finally arrives, the instinct is to design new things. That’s what design gets hired to do. Nobody hands you an audit of what the model already holds. You have to go take that inventory yourself.
This isn’t one product’s quirk. Five years ago at Pinterest, working on ads reporting, advertisers kept asking for saved views, persistent state across the campaign hierarchy, filter and find instead of scroll. The reporting system held everything those workflows needed. In the design brief I wrote at the time, one of my open questions to engineering was literally: are filtering, sorting, and search pulling from the same source of truth, and what does it mean if they aren’t. Same diagnostic, before I had a name for it. The pain showed up in research as annoying and frustrating, when it was really an architecture conversation nobody was having.
The counterweight matters. Rendering everything the model holds is its own failure. Part of the original mess was too much rendering identically, which is surfacing with no judgment in it. One rule is non-negotiable: never surface what the system can’t actually back. Suggesting capability the stack doesn’t have is worse than hiding capability it does.
The working rule is simpler than it sounds. Surface what serves the person’s next decision. Keep the system exhaust hidden.
If you run an AI product, here’s tomorrow morning. Take the one screen your people live in. Pull up the actual record behind it and list every field it carries. Then list what the screen shows. The gap between those lists is a roadmap you already paid for.
Then ask your engineers what they built hooks for that nothing renders yet. They know. They’ve been leaving reserved fields and status flags in the code the whole time, waiting for someone to make it experience. That answer costs a coffee. It’s usually worth a quarter of roadmap.