Generative UI Playbook: Let AI Choose the Workspace, Not the Permissions

An AI can lay out a comparison table on the fly, drop in a date picker, or assemble a short review form. The question is whether letting it do that helps your business finish tasks or quietly hands it a tool you cannot take back. A useful starting pattern: chat to clarify, a bounded workspace to compare or edit, and a separate fixed confirmation to commit. Treat that as a design recommendation, not a finding that generated UI outperforms the alternatives; nothing in the underlying sources measures a universal winner.

The older idea has a longer history than the marketing. Ben Shneiderman’s 1997 paper, Direct Manipulation for Comprehensible, Predictable and Controllable User Interfaces, argues that interfaces help most when the user can see what is happening, predict what will happen next, and control the result. The original SUPPLE project at Harvard describes decision-theoretic generation of interfaces adapted to a person’s abilities, devices, preferences, and tasks, and reported laboratory benefits for ability-based interfaces for users with motor impairments. W3C’s Model-Based UI Introduction describes task, abstract, and concrete UI layers in the Cameleon Reference Framework and labels its benefits as potential. The novelty framing today is that a language model can propose or select a workspace from natural-language context. The challenge is older than the technology. The pattern is the same: adapting to context without making the experience unpredictable.

What it actually is, and what it is not

Generative UI is an interaction pattern in which an AI system selects, populates, or composes part of a usable interface at runtime in response to a task. The definition deliberately includes selecting an existing comparison card; novelty of visual layout is not required.

Several independently maintained implementations describe the pattern without claiming it solves safety or correctness. Google’s A2UI README describes a flow that disconnects the generation of UI from the execution of UI. Vercel Labs’ json-render defines a component catalog and registry, and its maintainers write that the AI can only use components in the catalog. LangChain’s Generative UI for React guide documents sending component-associated UI messages to a React application. The catalog limits the menu. It does not establish factual accuracy, authorization, accessibility, or appropriate data use.

That distinction is the practical question for a business owner. OWASP’s LLM06:2025 Excessive Agency guidance recommends implementing authorization in downstream systems rather than relying on an LLM to decide if an action is allowed. A bounded workspace reduces the surface that needs authorization. It does not eliminate the need to authorize what the workspace actually does.

A non-AI alternative exists. JSON Forms explicitly separates a data schema describing the data from a UI schema describing control order, visibility, and layout, and maps them to UI components at runtime. Schema-driven rendering can exist without model-driven selection. If your task is structured and the controls are familiar, a deterministic conditional form may be enough.

Choosing the right surface for the task

Apply the choice to one task, not to the whole company. The underlying support is recognition rather than recall in conventional usability guidance (Nielsen’s heuristics) and context and correction in human-AI interaction guidelines). No source establishes a universal winner.

• The user does not yet know what they need. Start with chat. Dialogue can clarify missing requirements before choosing fields. A fixed checklist is the falsifier if it gets the user to the correct task with fewer corrections.
• Compare several options across the same attributes. A bounded table plus filters makes the alternatives visible. The falsifier is that users overlook caveats, compare wrong units, or perform worse than with a fixed comparison tool.
• Collect predictable fields repeatedly. A fixed form provides stable locations and known validation. The falsifier is that context-specific field selection demonstrably reduces errors without hiding mandatory fields.
• Task changes the combination of familiar controls. A schema-driven composition pilot selectively assembles useful controls. The falsifier is that catalog maintenance and inconsistent arrangements outweigh the time saved.
• Irreversible or high-impact action. Keep a fixed confirmation and a separate permission service. A static panel alone is still insufficient for understanding what is being approved.
• Explain a result or discuss uncertainty. Keep text or chat beside the workspace. Controls do not replace explanation.

These are pilot selection aids, not evidence that all comparison tasks deserve generated tables. We have no matched user study for any of these rows in your organization.

Eight steps before a real pilot

1. Pick a narrow, reversible task. Write the finish condition in ordinary language, and specify the existing chat or fixed workflow as a baseline. Choose a read-only or draft-only surface first. NIST’s AI Risk Management Framework calls for contextual risk assessment; its overview treats governance and measurement as separable characteristics.

2. Define a small component and action menu. Start with familiar controls the organization already understands: text, a table, filters, a date input, a draft editor, a review card, and an explicit cancel route. Define the data each may display, missing-data behavior, valid units, and permitted action names. Catalog size is not an achievement metric; each addition introduces behavior to maintain.

3. Separate draft structure, business data, and permissions. Require the application to distinguish model-suggested UI structure, verified business values, the user’s draft edits, and server-checked permission. A proposed price is not an approved price. A hidden or disabled button is not an authorization control.

4. Make consequential actions a separate review event. Keep prepare separate from commit. A stable review identifies what will change, the affected records or recipients, amounts and units, the current authoritative values, and the user’s ability to cancel. If the data changed since the draft, show the change and require a fresh review. A human approval click is only meaningful when the human can understand the proposal.

5. Preserve consistency, accessibility, and recoverability. WCAG 2.2 covers complete processes, not only attractive isolated components. Test the assembled workflow, including loading, updates, failure, and confirmation, not just each catalog item. The catalog is an opportunity to reuse known behavior, not evidence of accessibility.

6. Inspect privacy and rendering boundaries. Ask for a field-level data map covering prompts, UI payloads, action payloads, logs, analytics, storage, and any external content loads. The ICO’s data minimisation guidance describes adequate, relevant, and necessary data; this is operational caution, not a legal conclusion. Treat arbitrary generated HTML as a separate product decision; the WHATWG HTML specification explains that enabling both scripts and same-origin access can allow removal of the sandbox and breakout.

7. Evaluate outcomes on real tasks and adverse cases. Compare generated, chat, and fixed variants using the same underlying data and the same correct-answer rubric. Include ordinary users, frequent users, relevant accessibility needs, ambiguous requests, missing values, conflicting records, interruption, network failure, and a malicious instruction in retrieved content. OpenAI’s evaluation guide recommends scoped, task-specific evaluations and human calibration of automated scoring.

8. Set go or no-go rules and a refresh owner. Write explicit rollout conditions before seeing the result: no unauthorized writes, no missing required review information, no loss of task completion for supported access needs, and a meaningful task benefit over the best baseline that remains after recovery and maintenance are counted. Keep a manual route and a switch to disable dynamic composition.

Failure modes and what would falsify the pilot

These are stronger than “users liked the demo.”

• Shifting layouts destroy learned navigation. Pin useful layouts, keep stable actions, and keep a fallback. The falsifier is that repeated users finish less accurately or take longer after adaptation.
• Attractive visual answers increase overtrust. Show source, missingness, editable assumptions, and limits. The falsifier is that users approve incorrect outcomes more often than with the chat or fixed baseline.
• Valid structure carries false or wrong-unit values. Validate against authoritative sources and show units. The falsifier is any critical wrong-value presentation that reaches commit review uncorrected.
• Streaming moves focus or loses entered work. Specify update, focus, and state behavior; test failure transitions. The falsifier is that a supported keyboard or assistive-tech user cannot complete the process.
• A generous catalog becomes disguised arbitrary execution. Review component behavior and external resource use. The falsifier is that a new component bypasses the intended permission or rendering boundary.
• Human approval becomes a ceremonial click. Test comprehension and show the exact consequential change. The falsifier is that users cannot explain what they approved, or that an unreviewed change is executed.

Stop or narrow the pilot when falsifiers are observed. Do not keep adding model capability to compensate for a broken interaction or permission design.

Done means

A first reversible pilot produces a draft or read-only surface that:

• matches a chat or fixed-form baseline on task completion for ordinary users,
• shows discernible error messages with units and the affected records,
• recovers cleanly from interruptions and network failures without losing entered work,
• has keyboard-only and screen-reader users able to finish the same task,
• separates model suggestion, verified data, draft edits, and authorized action,
• requires a meaningful human review with the exact consequential change before commit,
• leaves a manual fallback and a switch to disable dynamic composition.

If a pilot cannot meet those seven checks on real tasks and adverse cases, narrow it further or stop it.

What this article does NOT cover

It does not adjudicate which framework or vendor wins. It does not establish a general productivity lift, conversion increase, cost saving, superior model, or best vendor for generative UI; the underlying sources provide implementation descriptions, historical research, standards, and evaluation methods, not a matched contemporary benchmark of generated UI against chat and fixed UI. It is not a setup guide, not a release-pinned technical walkthrough, not a regulatory or legal verdict for a specific jurisdiction, and not a certification that schema validation, sandboxed iframes, or a controlled component catalog constitute security or accessibility compliance. No model inference, product installation, UI rendering, browser or assistive-tech test, permission test, or benchmark was run in the research behind this article. Provider-specific retention, training-use, regional processing, and contractual terms are not researched because no provider was selected.

Related guides

• Context Engineering — what to feed the model and what to leave out.
• Harness Engineering — the surrounding agent setup that turns a model into a product.
• Loop Engineering — observe, plan, check, repeat, with a stop condition.
• Proactive Agents — the permission ladder decides, not the model.
• Agent Containment — the boundary that matters after a bad agent decision.

Research basis: shared/abs-research-briefs/aidb/generative-ui-playbook/generative-ui-playbook-research-2026-10-10.md (verified 2026-10-11, dossier SHA256 c2aed70ca68acdff51dd48dc0701adc0261d0c22b59e564810b9cfc239310cbb).