Topic Proposal: Fallback UX for Generative UI — Recovering When Model Output Breaks

[JacKane21]

Topic Proposal: Fallback UX for Generative UI — Recovering When Model Output Breaks

Hi @zahlekhan, the creator program has strong briefs around explaining generative UI, token cost, rendering, voice agents, and MCP workflows. One production gap I do not see covered yet is fallback behavior: what an app should do when model-generated UI is incomplete, invalid, unsupported, unsafe to render, or mismatched with the user's current state.

Why This Topic

Generative UI feels magical in demos, but production apps need boring reliability. A model can emit a component name the renderer does not support, skip a required prop, stream half of a table, request an action the user cannot take, or produce a UI that is technically valid but stale because underlying data changed mid-response.

If teams do not design fallbacks deliberately, the failure mode is usually either a broken blank card or a silent downgrade to text. Neither is good enough for workflow software, support tools, dashboards, or agent-driven interfaces where users need to understand what happened and what they can safely do next.

This article would make fallback UX a first-class part of generative UI architecture instead of an afterthought.

Proposed Angle

A practical developer guide: treat model-generated UI as an optimistic interface proposal that must pass validation, rendering, permission, and state checks before becoming the user's working surface.

The core idea: every generated interface should have a fallback ladder.

1. Schema fallback — recover when the generated structure is incomplete or invalid.
2. Component fallback — handle unknown components, missing props, unsupported variants, and partial streaming output.
3. Permission fallback — show disabled or explanatory action surfaces when the model proposes actions the current user cannot run.
4. State fallback — detect stale data, conflicting state, and expired tool results before the UI offers next steps.
5. Text fallback — degrade to a useful explanation only after preserving as much structured context as possible.

Proposed Structure (~1800-2200 words)

1. The happy-path demo is not the product

   • A short example of a generated approval card that breaks because one required field is missing.
   • Why "just ask the model again" is not a UX strategy.

2. Think in fallback ladders

   • Generated UI as proposal, not authority.
   • The checks between model output and rendered UI: parse, validate, map components, hydrate data, authorize actions.

3. Recovering from invalid or partial output

   • How to preserve valid subtrees.
   • When to render skeletons, repair prompts, retry, or downgrade a single component.
   • Example pseudo-code for a renderWithFallbacks() pipeline.

4. Action safety and permissions

   • A model may describe a button, but the app decides whether the action exists and whether this user can run it.
   • Patterns for disabled actions, re-auth prompts, confirmation steps, and audit-friendly errors.

5. Stale state and tool-result drift

   • What happens when the generated UI references data that changed after the tool call.
   • Version checks, optimistic refresh, and "this changed while you were reviewing" states.

6. Designing fallback copy that does not feel like an exception trace

   • How to tell users what is available, what failed, and what they can still do.
   • Examples for dashboards, forms, and approval workflows.

7. Where OpenUI fits

   • Use OpenUI as the concrete implementation path: constrained component vocabulary, renderer boundaries, validation before rendering, and fallback components that match the app's design system.
   • Keep it framework-practical, not a sales pitch.

Deliverable

• Markdown article under Articles/
• Small code-shaped examples for a fallback rendering pipeline, component fallback registry, and action authorization boundary
• No companion app unless you want the piece turned into a tutorial; I would keep this as an article/guide first

Tone

Developer-to-developer, practical, and honest about tradeoffs. The piece should be useful to a team already building generative UI and asking, "What happens when the model output is almost right, but not quite?"

Compensation

$100 USD guide tier, if the topic fits the program and you would like me to write it.

I will wait for assignment/confirmation before opening a content PR so I do not add duplicate work to the queue.

[JacKane21]

Quick update: I drafted the article locally so I can turn this into a PR quickly if the topic is accepted. Current draft is ~2,000 words and covers schema, component, permission, state, streaming, and text fallback ladders with TypeScript-shaped examples. I will still wait for assignment/confirmation before opening the PR, per the creator-program workflow.

[vishxrad]

@JacKane21 can you share what you have written for this issue?

[JacKane21]

Sure, sharing the current draft below. I have not opened a PR yet; I will wait for assignment/confirmation before turning this into a content PR.

Fallback UX for Generative UI: Recovering When Model Output Breaks

Generative UI demos usually show the happy path: the model understands the request, emits the right component tree, the renderer streams it in, and the user gets a useful interface instead of a wall of text.

Production has more interesting weather.

A model can emit a component your renderer does not support. It can skip a required prop. It can stream half of a table and then drift into prose. It can propose an action the current user is not allowed to run. It can build a beautiful approval card from data that changed two seconds ago.

None of those failures mean generative UI is unusable. They mean model-generated UI needs the same thing every production interface needs: a recovery plan.

The useful mental model is this:

A generated interface is a proposal, not authority.

The model proposes a UI. The application decides whether that UI is valid, safe, current, and useful enough to render.

The Happy Path Is Not The Product

Imagine an assistant that helps an operations team approve vendor payments. A user asks:

Show me the invoices that need approval today.

The assistant generates an approval card:

<ApprovalCard
  vendor="Northwind Services"
  amount="$8,240"
  dueDate="Today"
  actions=["approve", "hold"]
/>

That card is much better than a paragraph. It can show the invoice, expose the available actions, and keep the user inside the workflow.

Now remove one field:

<ApprovalCard
  vendor="Northwind Services"
  dueDate="Today"
  actions=["approve", "hold"]
/>

What should the app do?

Rendering a broken card is bad. Dropping the entire response is also bad. Falling back to "Something went wrong" wastes the context the model did get right.

A good fallback keeps as much useful structure as it safely can. Maybe the approval card becomes a review card with the amount marked unavailable. Maybe the approve action is disabled. Maybe the app asks the tool layer to refetch the invoice before showing any action.

That decision should not be improvised inside a catch block.

Think In Fallback Ladders

Generative UI needs a fallback ladder: a predictable sequence of checks and recovery steps between model output and rendered interface.

A simple ladder looks like this:

1. Parse the generated output.
2. Validate the component structure.
3. Map requested components to allowed components.
4. Hydrate or verify referenced data.
5. Authorize requested actions.
6. Render the best safe interface.
7. Fall back to text only when structure cannot be preserved.

Here is the shape in code:

type RenderResult =
  | { kind: "render"; node: React.ReactNode }
  | { kind: "partial"; node: React.ReactNode; warning: string }
  | { kind: "text"; message: string };

function renderWithFallbacks(
  generated: string,
  context: RenderContext,
): RenderResult {
  const parsed = parseGeneratedUI(generated);

  if (!parsed.ok) {
    return {
      kind: "text",
      message: summarizeParseFailure(generated),
    };
  }

  const validated = validateComponentTree(
    parsed.tree,
    context.componentRegistry,
  );

  if (!validated.ok) {
    const partialTree = keepRenderableSubtrees(parsed.tree, validated.errors);
    return {
      kind: "partial",
      node: renderFallbackTree(partialTree, validated.errors),
      warning: "Some generated sections could not be displayed.",
    };
  }

  const authorized = authorizeActions(validated.tree, context.currentUser);

  return {
    kind: "render",
    node: renderComponentTree(authorized.tree),
  };
}

The point is not this exact function. The point is where responsibility lives. The model does not get to render arbitrary UI directly. The renderer is a boundary.

OpenUI fits naturally into this pattern because a constrained component vocabulary gives the renderer something concrete to validate. The model can compose, but it composes from known pieces.

Schema Fallbacks: Recover Without Guessing

The first failure mode is malformed or incomplete structure.

For JSON-based UI, that might mean invalid JSON, missing required fields, or unexpected enum values. For a DSL such as OpenUI Lang, it might mean a component is syntactically incomplete or a stream ends before a nested section closes.

Do not treat every schema error the same way.

Some failures are local:

<Metric label="Revenue" value="$42k" trend="up" />
<Metric label="Churn" trend="down" />

The second metric is missing a value, but the first metric is still useful. A renderer can preserve the valid metric and replace the incomplete one with a neutral fallback:

Revenue: $42k
Churn: unavailable

Other failures are structural:

<ApprovalForm invoiceId="inv_123">
  <ApproveButton action="approve_invoice">

If the form never closes and the action payload is incomplete, rendering the action is unsafe. The fallback should keep the invoice context but remove the action surface.

A practical schema fallback policy:

• Keep valid sibling components when one child fails.
• Replace invalid leaf components with typed fallback components.
• Drop unsafe action components unless the action payload validates fully.
• Preserve a compact explanation for users and logs.
• Feed structured validation errors back into retry or repair prompts.

This avoids the two lazy extremes: "render whatever the model wrote" and "throw away everything."

Component Fallbacks: Unknown Does Not Mean Blank

Component fallback is about vocabulary mismatch.

The model asks for:

<RiskHeatmap accounts={...} />

But your allowed library only has:

<RiskTable />
<RiskScoreCard />
<BarChart />

The renderer should not invent a heatmap. It should map, substitute, or explain.

A fallback registry can make that behavior explicit:

const fallbackRegistry = {
  RiskHeatmap: {
    substitute: "RiskTable",
    reason: "Heatmap is not available in this workspace.",
  },
  InlinePaymentApproval: {
    substitute: "ApprovalSummary",
    reason: "Payment actions require an explicit permission check.",
  },
} satisfies Record<string, ComponentFallback>;

This is especially important when multiple product surfaces use different component sets. An admin dashboard might allow charts, tables, and write actions. A support chat might allow summaries and links but not destructive actions. A mobile surface might reject dense layouts that are fine on desktop.

Fallbacks should be product-aware, not generic.

Fallback Components Beat Ad Hoc Copy

The easiest fallback to ship is a string. The better fallback is often a component with a smaller contract.

For example, an approval surface might expose both of these components:

type ApprovalCardProps = {
  invoiceId: string;
  vendor: string;
  amount: string;
  dueDate: string;
  actions: Array<"approve" | "hold" | "reject">;
};

type ApprovalSummaryProps = {
  invoiceId: string;
  vendor: string;
  amount?: string;
  dueDate?: string;
  reason: string;
};

ApprovalCard is the full interactive component. ApprovalSummary is the safe fallback. It can render with incomplete fields, but it cannot execute payment actions.

That distinction matters. If a generated approval card is missing a required amount, the renderer should not invent one, and it should not render a broken card. It can downgrade:

function fallbackApprovalCard(
  props: Partial<ApprovalCardProps>,
): ApprovalSummaryProps {
  return {
    invoiceId: props.invoiceId ?? "unknown",
    vendor: props.vendor ?? "Unknown vendor",
    amount: props.amount,
    dueDate: props.dueDate,
    reason: "Approval actions are hidden until required invoice fields validate.",
  };
}

The model still gets to communicate what it found. The application decides which interaction level is allowed.

Permission Fallbacks: The Model Does Not Grant Access

The most dangerous generated UI is often not malformed. It is plausible.

<Button action="refund_payment" label="Refund" />

That is a valid button. It may even be the right button for some users. But the current user might not have refund permission, the transaction might already be closed, or the workspace might require approval from a second admin.

The model can describe the action. The app owns authorization.

A useful action boundary has three checks:

1. Does this action exist?
2. Is this user allowed to run it?
3. Is this action valid for the current resource state?

The fallback is not always to hide the action. Sometimes hiding creates confusion. If a user expects to approve an invoice but cannot, a disabled button with a reason is often better:

Approve disabled
Requires workspace admin permission.

For sensitive actions, the generated UI should never be the final execution boundary. The generated component can request intent. The application still runs confirmation, permission checks, audit logging, and server-side validation.

async function runGeneratedAction(
  action: GeneratedAction,
  context: ActionContext,
) {
  const definition = actionRegistry[action.type];

  if (!definition) {
    return { ok: false, reason: "Unsupported action" };
  }

  const permission = await definition.canRun(context.user, action.payload);

  if (!permission.ok) {
    return { ok: false, reason: permission.reason };
  }

  return definition.run(action.payload);
}

This keeps generative UI from becoming generative authorization.

State Fallbacks: Data Changes While The Model Thinks

Generated interfaces are often built from tool results. Tool results have a timestamp. Real systems keep moving.

A model may produce:

Invoice inv_123 is ready for approval.

But by the time the card renders, someone else may have approved it, rejected it, edited the amount, or closed the vendor account.

This is not a model problem. It is a state problem.

For generated UI that references live resources, include version information in the tool output and validate it before actions render:

type InvoiceToolResult = {
  invoiceID: string;
  version: number;
  status: "open" | "approved" | "rejected";
  amount: number;
};

Then the renderer can ask:

• Does this resource still exist?
• Is the version current?
• Is the status compatible with the proposed UI?
• Should we refresh before rendering actions?

A stale-state fallback might say:

This invoice changed while the response was being generated. Refreshing the approval options.

That is much better than showing a dead approve button or, worse, approving the wrong state.

Text Fallbacks Should Be Useful, Not Apologetic

Text fallback is still important. It is just not the first move.

Bad fallback copy:

Something went wrong.

Better fallback copy:

I found three invoices, but could not render the approval table because one invoice is missing an amount. You can still review the invoice list below.

Best fallback copy preserves structure:

Invoices found:
- Northwind Services: amount unavailable, due today
- Rivera Design: $1,900, due tomorrow
- Atlas Hosting: $240, overdue

Approval actions are hidden until the missing amount is refreshed.

The fallback tells the user:

• what succeeded,
• what failed,
• what is still safe to do,
• what will happen next.

That is the difference between a product failure and a recoverable state.

Streaming Needs Partial Fallbacks

Generative UI often streams. Streaming creates a specific UX problem: the interface can be valid at one moment and invalid at the next.

For example, the model starts a dashboard:

<Dashboard>
  <Metric label="Revenue" value="$42k" />
  <Table>

At this point, the metric is renderable. The table is not. A streaming renderer should not block the metric while waiting for the table to finish.

Useful streaming fallback behavior:

• Render complete components as they become valid.
• Use skeletons for open containers.
• Time out incomplete children independently.
• Never expose actions until their payload and permission checks pass.
• Mark repaired or substituted components in logs, not necessarily in user-facing UI.

The user does not need to know every parser recovery detail. The app does.

Instrument Fallbacks Like Product Events

Fallbacks should not disappear into console logs. They are product signals.

If a generated interface repeatedly falls back from RiskHeatmap to RiskTable, maybe the component library is missing an important visualization. If the same action is often generated but denied by permissions, maybe the assistant needs better role context. If streams often time out inside one component, maybe that component contract is too large for the model to generate reliably.

Capture fallback events with enough structure to answer those questions:

type FallbackEvent = {
  surface: "invoice_assistant" | "support_copilot" | "admin_report";
  fallbackKind: "parse" | "schema" | "component" | "permission" | "stale_state";
  requestedComponent?: string;
  renderedComponent?: string;
  actionType?: string;
  userRole?: string;
  recoverable: boolean;
};

Avoid logging raw model output if it may contain private data. Log the class of failure, the component names, and the decision the renderer made.

This turns fallback UX into an improvement loop. You can see which components need clearer props, which prompts are asking for unavailable surfaces, and which errors should become first-class UI states.

What Developers Still Own

Generative UI does not remove frontend engineering. It changes where the engineering pressure moves.

Developers still own:

• component contracts,
• allowed component vocabularies,
• validation,
• fallback components,
• action registries,
• permission checks,
• loading and stale-state behavior,
• accessibility,
• telemetry,
• test coverage.

The model owns composition. The application owns consequences.

That boundary is what makes generative UI shippable.

Where OpenUI Fits

OpenUI is useful here because it treats generated UI as structured output rendered through known components. That gives teams a clear place to enforce constraints.

A production OpenUI integration should define:

• which components the model can use,
• which props are required,
• which props can be repaired or defaulted,
• which components have safe substitutes,
• which actions require confirmation or permission checks,
• which fallback components match the app's design system.

The payoff is that fallback UX can be designed once and reused across generated surfaces.

Instead of every prompt trying to say "please generate valid UI," the renderer can enforce what valid means.

A Practical Checklist

Before shipping a generated UI surface, ask:

• What happens when parsing fails?
• What happens when one component is invalid but its siblings are valid?
• What happens when the model asks for a component we do not support?
• What happens when a required prop is missing?
• What happens when an action is valid but unauthorized?
• What happens when referenced data is stale?
• What happens if the stream stops halfway through a component?
• Which fallback events are captured for product and engineering review?
• What does a screen reader hear during fallback states?
• What do logs capture for repair and debugging?
• What is the final text fallback if no structure can be preserved?

If the answer is "the model should not do that," the system is not done.

The Bottom Line

The strongest generative UI systems do not assume the model will always produce perfect interfaces. They assume the model will usually produce something useful, then build a renderer that can preserve the useful parts and reject the unsafe parts.

That is the difference between a demo and a product.

Generated UI should be flexible at the model layer, strict at the boundary, and graceful at the user layer. When something breaks, the user should still understand what happened, what remains trustworthy, and what they can do next.