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. Then someone asks how you'd trust it, and the room goes quiet.

I want to argue that the wall is in the wrong place. The thing that makes a generated interface trustworthy is not a better model. It is 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 have spent the last year building exactly that apparatus twice — once for interfaces, once for actions — and only recently noticed they are the same machine.

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; a renderer maps it onto real components. Vercel's generative UI does this. The tool-driven widgets in the major assistants do this. My own genui package does this: 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 slow, it is not accessible, it cannot be audited, 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 is not where the pixels come from. It is whether the structure of the interface is selected from a menu or invented for the moment. Given a vocabulary large enough, layout freedom, and generated content, composition is indistinguishable from generation to the person using it. The constraint is not a capability ceiling; it is a safety property we should want. A polymorphic interface is one whose form is chosen per moment from a closed world — and the closed world is the point.

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, preferences, habits, a behavioral profile deep enough to predict them. This is the personalization industry's reflex, and I think it is wrong.

An interface does not need to know the person. It needs to know 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 is exactly the cadence a per-moment interface needs. A profile changes over months. Individualization comes from intent and situation; personalization comes from a dossier. Only the first can drive form.

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, not a status page. Rule R-07 means the "why" is the headline, not 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 human approver required means the identity of that approver is a first-class element. None of this requires knowing who the reviewer is. All of it requires knowing what the decision is.

That is the thesis in one line: the decision already contains the interface. We have been rendering decisions into fixed screens and asking people to 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 projects. They are the same project. One governs what an agent may do; the other governs what an agent may show. Both replace hope with a closed world and a gate. And the moment you put them together, 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; it can be a constrained one, or in many cases a deterministic function — 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. And the rendered surface is bound to the decision receipt — the interface carries the seal of the decision that produced it.

That last property is the one nobody else has. A generated interface that is signed by the decision it expresses is not a demo. It is 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. The answer is that generation must be bounded: the shell, the navigation, and anything that carries authority stay fixed; only the workspace is polymorphic. The seal never moves. The approve action is always in the same region even when everything around it is generated. Polymorphism is a property of the middle of the screen, not the edges.

Latency through prediction. Sub-200ms is the budget for something to feel like an interface rather than a page load. A large model cannot generate structure in that budget on every interaction. But it does not have to: the decision engine already knows the likely next states — approve, deny, request more evidence, escalate further. 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 is not generated when you click; 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. That is a performance problem, not a conceptual one. The rules are deterministic; deterministic rules are fast. The evidence pack I generate for auditors today, per release, becomes a receipt I generate per screen.

How far away

Bounded, registry-constrained, per-moment structural generation inside an operator surface: 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, and the reason is not that the idea is hard. It is that 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: two to four years, and I would argue it should never be allowed near an action. An interface that can be anything can be wrong in ways no gate can catch. The constraint is not a limitation we are waiting to lift. It is the design.

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 that an agent cannot read is dead weight. A design system that an agent can read but not be checked against is a liability. The only design system worth building from here on is one where 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.