Generative UI Needs a Component Contract Before It Needs a Better Demo

The important question is not whether the UI looks real

Generative UI demos make two different claims feel like one:

1. A model can produce a plausible interface.
2. The interface can safely cause a real-world action.

They are not the same claim.

AppLess is a useful open-source experiment to read through that lens. It streams a UI language from a model and renders it through React Native. Its README also makes an unusually important limitation explicit: without real integrations, screens such as orders or payments are simulated. Plausible content is not proof of a completed transaction.

Not tested / not run. This is a source-reading note based on the public repository and README, not a performance, security, or production-readiness review.

A component contract is a better starting point than arbitrary UI output

The model-facing surface lives in src/genos/ui/contract.tsx. It defines component names, prop schemas, and descriptions in one place. The repository can then implement different renderers for different visual systems without changing the vocabulary available to the model.

That separation is valuable:

• A team can review the components a model is allowed to compose.
• Properties have schemas instead of becoming one-off JSON fields invented by a prompt.
• Platform-specific renderers can change presentation without changing UI semantics.
• Adding an ability becomes an interface decision, not only a prompt edit.

The application layer in GenOS.tsx maintains app sessions, screen stacks, and generation state. From the source structure, the generated output is meant to be rendered through a constrained native component layer rather than treated as an unrestricted web page.

Rendering authority is not action authority

A component contract answers: what may be displayed?

It does not answer:

• May the model read a user's calendar, location, or account data?
• Which tool executes when a user presses a button?
• How is that tool scoped and authorized?
• What server-side checks prove that an order, payment, or update actually happened?

I would separate a generative UI system into two paths:

model output -> component contract/schema validation -> native renderer
user action -> explicit tool authorization -> server-side auth and business validation -> verifiable result

The first path controls presentation. The second one owns side effects. A generated “Payment sent” screen must not become evidence that payment happened.

Who should investigate this pattern?

This approach is promising for teams building assistants, dynamic forms, internal tools, or high-fidelity prototypes where the allowed components and actions can be deliberately limited.

It is not a drop-in answer for payments, healthcare, bookings, or account management. In those domains, the UI contract is only the front-end boundary; authorization, auditing, idempotency, and server confirmation remain essential.

AppLess is an experiment, not a production recipe. Still, its explicit separation between generated UI and simulated actions is the right instinct: let the model compose from a bounded interface, then put data access and consequential actions on a separate, auditable authorization path.

Sources: repository, README, component contract, app state layer, and repository releases.

AI-assisted disclosure: This article was drafted with AI assistance and reviewed against the linked public sources. No third-party code was installed, built, or run.