The GenUI demo is rarely the problem. Everyone in the room wants the upside: faster experiences, more personalized interfaces, new ways to connect users to products and information. The project stalls in the meeting after the demo, when product, engineering, and compliance stakeholders ask some version of the same question: what would need to be true for this to be safe enough to ship?
That is the right question. Not “is GenUI safe?” Not “can the model hallucinate?” But this: what controls, artifacts, and validation steps exist before GenUI reaches a user? Approval gets easier the moment teams stop describing GenUI as magic and start showing how it is constrained, grounded, and checked. This post is the checklist for doing exactly that.
Start with the real risks
Generative UI, or GenUI, is a way for an LLM to emit a user interface in terms of components an app already knows how to render, using the A2UI protocol. The stakes are higher than chat, and the reason is simple: the output is an interface, and users act on interfaces. Our engineering deep dive on hallucination defense in GenUI walks the mechanics in depth. This post covers what a reviewer needs.
When people talk about GenUI risk, they usually collapse everything into “hallucinations.” That is too vague to act on. VGV’s Brian Egan breaks the problem into three categories, and a single scenario shows why the distinction matters. For example, say a customer asks their bank’s GenUI app for the fastest way to pay down a credit card.
First, content hallucinations. The system makes up facts, products, policies, or answers. The response is a well-formed offer card for a balance-transfer product with a 0% intro rate the bank does not offer.
Second, structural hallucinations. The system generates UI that does not match the approved catalog. It returns plain text the client cannot render, invents a component that does not exist, omits required properties, or picks a valid component that fails the job, like a spending-trend chart when the customer asked for a payoff plan.
Third, intent hallucinations. The system responds outside the job it is supposed to do. The customer types “waive my late fees for the year,” the model complies, and the client faithfully renders a confirmation card for a waiver that was never approved.
If you have read the four-layer defense post, the map is direct. Content hallucinations are its data layer, structural hallucinations cover its structural and semantic layers, and intent hallucinations are its safety layer. Same problem, sliced for the reviewer instead of the engineer.
No single defense catches all three. A team that only talks about accuracy but ignores structure, permissions, and fallback behavior has not de-risked GenUI. It has de-risked one third of it.
Bring artifacts, not assurances
If a VP of Product wants GenUI approved in one review cycle, they should not walk in with a vision deck. They should walk in with a small set of concrete artifacts that show how the system behaves under constraint. Here is the five-part checklist we use.
1. A constrained component catalog
The first thing reviewers should see is that the model cannot invent the interface from scratch. It composes from an approved set of UI building blocks, with a clear registry, defined allowed properties per component, and examples of valid compositions.
In the GenUI Kit, this is the catalog package. It lists every component the model may emit along with its JSON Schema, and it is the single source of truth. The Flutter frontend reads it to know which widgets to build. The backend reads it to render each schema directly into the system prompt, so the model sees the exact JSON shape it must return per component rather than guessing.
The catalog also carries the component-choice guidance that prevents the “valid but wrong” failure. A short catalog prompt tells the model when a flight card beats a line chart beats plain text. Keep its scope narrow. It governs component choice, not protocol mechanics and not the app’s voice. Those live in their own prompts, and the backend concatenates all three per request.
This artifact is the main defense against structural hallucinations, and it makes the output auditable. If the model emits a component that does not exist or adds unsupported properties, that is immediately detectable.
2. Grounding to verifiable IDs and source systems
The second artifact is proof that the model does not generate factual content out of thin air. The pattern is simple. The model references a specific ID, and the application fetches the actual data from the source system. Instead of writing the contents of a product card, the model indicates which product ID to show, and the app retrieves and renders the real record. The same logic covers FAQs, policies, and account data.
There are two mechanisms, and the split matters for cost. Tools handle data the model must fetch during generation, like inventory, prices, and a flight-search API. Each tool call is a full model round trip with real latency. Context injection handles facts the server already knows at request time, like the signed-in user’s home airport, locale, and the current time. Those merge into the prompt with no round trip. Pick tools for data the server has to go fetch. Pick injected context for data it already has.
One guardrail: everything injected lands verbatim in the prompt. Never inject secrets or unscreened client input.
In the banking scenario, this is the difference between an invented 0% offer and a card populated from the bank’s live product catalog, with rates coming from the system of record instead of the model. The more the model points to verified entities instead of writing them, the easier the system is to explain in review.
3. Validation before anything reaches the user
A constrained catalog is not enough on its own. Even a well-instructed model occasionally returns plain prose or JSON missing a required field. Teams need to show what happens between the model’s response and the user’s screen.
Every output gets checked against the catalog and schema. Does the component exist? Are required properties present? Does the response conform to the expected structure? In the kit, a response validator rejects the miss and retries the call once, a safety net for the rare bad generation.
The approval conversation changes when the answer is not “we prompt it carefully” but “we validate every output before render.” And just as important, teams should show what happens when validation fails. A system with only a happy path is not approval-ready.
4. Access control on every data and tool path
One major failure mode has nothing to do with the model inventing things. It is the model being allowed to retrieve information it should never have touched.
Every tool call and every data fetch runs through authentication and role-based access control. If a user cannot see a record, the model cannot retrieve it on that user’s behalf either, and every access is auditable.
Teams sometimes treat data access as separate from GenUI. It is not. When the interface is dynamically generated from model-linked tools and data, permissions are part of the safety model, and reviewers will ask.
5. Fallbacks for uncertainty, invalid output, and off-intent requests
The last artifact is the one teams neglect most. What happens when the system is wrong, uncertain, invalid, or off-task?
This is where intent hallucinations get caught. The defense sits at both edges of the request, screening the prompt coming in and the response going out, so the fee-waiver request never reaches a component the model could fill in. Teams can add an intent-validation step that checks whether a response matches the system’s purpose before allowing it through. That check adds latency, so the tradeoff has to be weighed per product.
Whatever the exact method, approval-ready systems have explicit failure design. Safe refusal, fallback UI states, and escalation paths are part of the architecture, not edge cases deferred to later.
A useful clarification: GenUI vs server-driven UI
Reviewers familiar with server-driven UI often ask what is actually new here. Dynamic composition is not new. Teams have assembled interfaces from predefined components for years, alongside search systems and recommendation models. What changes with GenUI is the generation layer and the flexibility of the model-driven decisions behind it.
That is why approval should not get stuck on labels. The question is never whether the system is called AI. The question is whether its outputs are constrained, grounded, and validated. If they are, reviewers have something concrete to evaluate. If they are not, the architecture is still too loose to ship.
The questions every approval-ready team can answer
Before shipping GenUI, a team should be able to answer these with artifacts instead of assurances:
- What is the model allowed to generate, and what is it not allowed to generate?
- Where do facts come from?
- How are inputs and outputs sanitized, both what enters the prompt and what leaves for the screen?
- How is UI output validated before render, and what happens when validation fails?
- What data can the model access, and how are permissions enforced?
- How does the system stay on-task?
- What is the fallback when output is uncertain, invalid, or off-intent?
The controls are the approval
GenUI does not become safer because a team says it is controlled. It becomes safer when the controls are explicit, reviewable, and enforced in the product. Each of the five artifacts answers a question no other artifact can. The catalog answers what the model may generate. Grounding answers where facts come from. Validation answers what stands between a bad generation and the screen. Access control answers what the model may touch. Fallbacks answer what happens when everything else says no. A team missing one artifact is walking into review with an open question, and open questions are where approvals stall.
Bring these five artifacts to your next architecture review and the conversation shifts from an abstract argument about AI risk to an inspection of system design. That is a conversation teams can win.
The GenUI Kit ships every control on this checklist, from the catalog and prompt architecture to the validator and quality gates a Flutter team needs to run generative UI in production. The alpha waitlist is open. For adjacent reading, see the VGV blog’s GenUI archive.
