I asked an assistant what was on my calendar, and it answered correctly: a meeting, a time, a room, four people, a link to join. It came back as five lines of labeled text.
The product those four people use every day has a calendar component for exactly that. It converts the time to your zone, checks whether the room is free, and gives you a button to accept. A screen reader announces it as an invitation instead of reading out field names. The assistant could have drawn it. It didn't know that it should.
That's a selection problem, not a rendering problem. The system had published what the component looks like. It hadn't published when to use one over the other.
Call the missing half a selection contract: the rules that decide which content belongs in which component. A set of facts becomes a card or a list row. A status becomes a badge or a sentence. A time, a place, and four names become an invitation or a table. Every design system has these rules. No published system writes them down.
Every new standard answers how, not which
Generative UI means an assistant hands back working interface instead of words: a card with buttons, a map, a form you can fill in, rendered in the conversation. The standards for it arrived quickly, and all of them are careful about drawing.
The Model Context Protocol lets an assistant reach services it didn't ship with, like your calendar. Its Apps extension, specified in January 2026, defines how an assistant returns interface rather than a paragraph. The surrounding application passes down its own colors, type, and corner radius, so the result doesn't read as foreign. The specification deliberately ships no component library, because no single library works in every place these things get displayed. That's the right call for a protocol. It also means the document says a great deal about how a returned interface should look and nothing about what it should be.
OpenAI's Apps SDK went further and shipped components: a list, a map, an album, a carousel, and a shop layout, plus three ways to present them. Its planning guidance asks builders useful questions. Is this something a person reads, or something they edit? Should it remember where they left off? A developer answers each one in advance, before anyone types a request. So the selection decision still gets made. It's made once, by one person, for every user who will ever see that capability.
The half a system never wrote down
A design system carries two agreements and publishes one.
The rendering agreement is documented exhaustively: appearance, states, behavior at narrow viewports, accessibility requirements, restrictions on use. A designer can look it up in a minute.
The selection agreement lives in critique. Someone holds up a screen, a reviewer says the status should be a badge rather than a sentence, and the reason gets said out loud once and recorded nowhere. That worked, because a person sat between the information and the screen every single time. You don't write down the part somebody reliable is going to supply.
For example, on a system serving a few hundred internal products, the most expensive support my team gave wasn't help using a component. Teams could read. It was answering which component something should be. Those conversations filled office hours and stretched design reviews, and almost none produced documentation, because each answer felt like it belonged to the one screen that prompted it. Each cost an hour of two people's attention and left nothing behind for the next team to reuse.
What changes when nobody answers
Generative UI removes that person at the moment they were doing the most work. The arrangement gets decided per request, against information nobody previewed, for a user nobody met. There's no critique and no one to ask. What was tacit doesn't get approximated. It's absent.
The assistant that gave me labeled text wasn't weighing the invitation component against plain text and choosing plain text. The invitation was never a candidate. Documentation used to be a courtesy extended to the next designer. Now it's the interface, and a rule that lives in someone's head may as well not exist.
The strongest case for leaving it alone
Models keep getting better at interface work, and hand-written rules have lost to general capability in field after field. Writing your system's current opinions into machine-readable form commits you to this year's patterns, and those opinions need governing, with the same drift and review burden your component library already carries. The sharper version of the objection: a designer having a bad day makes one bad screen, and critique catches it. A bad selection rule makes ten thousand, and no one reviews any of them.
No study measures how often a model picks the component a design team would have picked, because nobody has defined what picking correctly means. The case here rests on the shape of the problem.
The objection predicts the wrong failure. Suppose a model chooses well nine times in ten. On a single screen that's a good result, and probably better than a rushed designer manages. But a user meets the same kind of information ten times a week and sees ten arrangements, none of them wrong. What a design system sells is that the eleventh screen costs less to learn than the first. The cost that matters lands on the tenth encounter, not on the average one, and ninety percent doesn't deliver it.
Design systems didn't start because designers couldn't draw a button. They started because forty designers each drawing a reasonable button produce forty reasonable buttons, and the user pays for all forty in attention. Now the forty drafts come from one model instead of forty people. The user still pays.
What a selection contract has to contain
A selection contract should start from what the content contains, not from what the person wanted. Not "the user wants to schedule something" but "this has a start, an end, a place, and a list of people." Content can be checked. Intent has to be guessed, and guessing is the thing you were trying to remove.
It should state its conditions in the open. For example: a card earns its boundary when its content is independently actionable. A list row is right when the content's value comes from comparing it against what sits above and below it. Designers say sentences like those in critique constantly. No documentation site holds them.
System teams must put the contract where the screen gets assembled, not only on a documentation page. A documentation page serves a person reading at design time with an afternoon to spend. Something composing at request time needs to ask a direct question and get an answer with a reason attached. shadcn's registry server already lets an assistant search a component library, including a private one, and pull a component from a plain-language request. That solves finding. It doesn't touch choosing, and choosing is the half that carries the design opinion.
Design leads can start this week with three screens the team shipped last month. Go block by block and say why each one sits in the component it sits in. The answers you can write in a sentence are your contract, already drafted by people who didn't know they were drafting it. The answers that come out as "that's how we do it" are the gap, and they're where your product drifts first, because they're the only rules nothing can enforce.
Conclusion
The standards for AI-generated interfaces have settled how an assistant draws something and left open what it should draw. That second question used to be answered live, by a designer, which is why no system ever wrote it down: somebody reliable was always going to supply the answer. Nobody supplies it now. A system that publishes its components and its appearance rules, while leaving selection in people's heads, will watch its own components get used correctly by accident. The user pays for the misses in attention. Write down which content belongs in which component, state the conditions that make each one right, and put the result where the screen gets assembled. A rule an assistant can't reach at that moment is a rule you don't have.
