The Interface Is a Decision

Every serious conversation about generative UI ends at the same wall. Someone says the interface should generate itself — not pick from templates, not fill a dashboard with data, but actually come into being, in real time, shaped by what the person is doing at that moment. Everyone nods, because everyone wants this. Then someone asks how you'd trust it, and the conversation is over.

I want to argue that the wall is in the wrong place. What makes a generated interface trustworthy turns out to be the same thing that makes a generated action trustworthy: a closed world of what is legal, a deterministic gate that checks every output against it, and a signed record of what was decided and why. I know this because I spent the last year building exactly that apparatus twice — once for interfaces, once for actions — and it took me embarrassingly long to notice I had built the same machine both times.

Composition is not the ceiling

The first objection to generative UI is that everything shipping today is composition, not generation. A model emits a structured description, and a renderer maps it onto real components. Vercel's generative UI works this way. So do the tool-driven widgets in the major assistants. So does my own genui package: an agent emits a wire format that can only compose registry components, the validator rejects anything else, and a 51-case fuzz suite confirms every injection is rejected or inert.

The objection assumes that "real" generation would be pixel-level — a model painting the frame. That exists in research. It is also slow, inaccessible, unauditable, and it must never be allowed to take an action, because there is no way to know what a painted button does until someone presses it.

So the honest line between composing and generating has little to do with where the pixels come from. It has to do with whether the structure of the interface is selected from a menu or invented for the moment. Given a large enough vocabulary, layout freedom, and generated content, composition is indistinguishable from generation to the person using it — and the constraint stops looking like a capability ceiling and starts looking like a safety property you would ask for on purpose. A polymorphic interface is one whose form is chosen per moment from a closed world. The closed world is what makes it shippable.

What the interface needs to know

The second objection is that a truly individualized interface would need to know everything about the user — their history, their preferences, their habits, a behavioral profile deep enough to predict them. This is the personalization industry's reflex, and I think it is wrong.

An interface can get by without knowing the person at all, provided it knows the task state and the decision state: what they are trying to accomplish, what is already known, what is missing, what is risky, what happens next, and what authority they hold over it. Those change every few seconds, which happens to be the cadence a per-moment interface actually runs at. A profile changes over months. Individualization comes from intent and situation, and a dossier — whatever else it may be good for — cannot drive form at that speed.

Here is what that looks like when it is real. An agent asks to refund a customer $1,240. The request is compiled against a taxonomy of intent — 29 domains, 173 categories — and resolves to finance.refund.issue. A policy set evaluates it: rule R-07, high-value refund, requires a human approver. The risk score is 64, base 40 plus modifiers. Confidence is 0.91 against a 0.85 threshold. Four of four pieces of evidence are present. The decision is ESCALATE.

Every one of those facts is a layout instruction. Escalated means the interface needs an approve/deny surface rather than a status page. Rule R-07 means the "why" is the headline instead of a footnote. Evidence 4/4 means the evidence panel collapses; evidence 2/4 means it expands and turns amber. Risk 64 means the amount is emphasized; risk 12 means it is not. A required human approver means the identity of that approver becomes a first-class element. Notice that none of this required knowing anything about the reviewer — only about the decision.

The thesis, in one line: the decision already contains the interface. We have been rendering decisions into fixed screens and asking people to go find the relevant parts. A polymorphic interface renders the decision as the screen.

The two machines are one machine

For the last year I have been building an authority layer for autonomous systems. Its job is to sit between an agent's intent and the action it wants to take: interpret the intent, classify it against a closed-world taxonomy, evaluate it against policy, and either issue a single-use, cryptographically signed authority token or refuse. No token, no action. Every decision produces a receipt that can be verified offline.

In parallel, I built an AI-ready design system. Its job is to let an agent build an interface correctly without reading the codebase: every legal token and component is enumerated in a generated registry; anything not in the registry is provably fabricated and unmergeable; a deterministic gauntlet — typecheck, lint, build, test, accessibility, registry check — gates every change with no model in the merge path. The principle I wrote at the top of that repo was "Instruction hopes the model complies. Structure checks."

I built these as two separate projects, on the theory that they were two separate problems. They are not. One governs what an agent may do, the other governs what an agent may show, and both replace hope with a closed world and a gate. Put them together and the generative interface stops being a research problem and becomes an engineering one.

The authority engine produces a decision state. A small generator — it does not need to be a large model; a constrained one will do, and in many cases a deterministic function will do — proposes an interface structure for that state, drawn only from the registry. The gauntlet, run at interaction time rather than at merge time, verifies the proposal: every component exists, every token is legal, every text/surface pair passes contrast, every interactive element maps to an intent the person is actually authorized to issue. Only then does it render. The rendered surface is bound to the decision receipt, so the interface carries the seal of the decision that produced it.

That last property is the one nobody else has, and it is the difference between a demo and evidence.

The hard problems, honestly

Three things sit between this and production, and none of them is model quality.

Trust through invariants. An interface that changes shape breaks spatial memory. People who cannot predict where the approve button will be feel manipulated, and they are right to. So generation has to be bounded: the shell, the navigation, and anything that carries authority stay fixed, and only the workspace is polymorphic. The seal never moves. The approve action sits in the same region even when everything around it is generated. Put another way, polymorphism belongs to the middle of the screen, not to the edges.

Latency through prediction. Sub-200ms is the budget for something to feel like an interface rather than a page load, and a large model cannot generate structure inside that budget on every interaction. Luckily, it does not have to. The decision engine already knows the likely next states — approve, deny, request more evidence, escalate further — so the interfaces for those states can be generated ahead of the interaction and verified in the background. This is where "predictive" earns its place in the name. The interface was not generated when you clicked; it was generated when the decision was made, for every branch you might take.

Verification at runtime. Everything I built for merge-time gating — the registry check, the contrast gate, the accessibility sweep — has to run in the render path. This is a performance problem rather than a conceptual one, and deterministic rules are fast. The evidence pack I generate for auditors today, once per release, becomes a receipt generated per screen.

How far away

Bounded, registry-constrained, per-moment structural generation inside an operator surface is buildable now, by anyone who already has a machine-readable registry, a validator, and a source of decision state. That is a short list of organizations — not because the idea is hard, but because almost nobody has done the unglamorous work of making their design system a closed world and their decisions machine-legible. The ones who have are a year ahead and don't know it yet.

Unconstrained generation — a model with no registry, painting whatever it judges best, at interaction latency — is further out, call it two to four years, and I would argue it should never be allowed near an action regardless. An interface that can be anything can be wrong in ways no gate can catch, which is why I treat the constraint as the design rather than as a limitation we are waiting to outgrow.

What this means for design systems

If this thesis is right, the design system stops being a library and becomes a grammar. Its value is no longer the components; it is the registry that enumerates them, the tokens that constrain them, and the gate that checks every sentence written in it. A design system an agent cannot read is dead weight, and one an agent can read but cannot be checked against is arguably worse. From here on, the registry is the product and the components are the proof.

That is what I built. It was supposed to be a way to make agents stop hallucinating buttons. It turned out to be half of a generative interface. The other half was sitting in the repo next to it, signing tokens.

The interface is a decision. Build the decision well, and the interface follows.

Things I've built that this draws on: an AI-ready design system with DTCG tokens in three tiers, a build-failing WCAG-AA contrast gate, react-aria components with generated closed-world registries, a compiled machine surface (llms.txt, agent skills, editor rules, MCP server), a deterministic validation gauntlet with wrong→right eval pairs, and a generative-UI wire format with a fuzz-tested validator; and an authority runtime for autonomous systems with an open intent taxonomy (29 domains / 173 categories), deterministic policy evaluation, Ed25519 single-use authority tokens, and offline-verifiable decision receipts.