More room for product innovation
Put reusable screen infrastructure underneath the roadmap, so teams can focus on the workflows that make their product valuable.
A new chapter for enterprise software
Your products already know a great deal about the business. LiveUI gives them a flexible way to put that knowledge in people’s hands.
Bring new screens to existing applications. Turn a request into a working interface. Create a common foundation for web, mobile and AI.
Discover the opportunity ↓01 / The opportunity
A new customer requirement. A different approval process. A supervisor who needs another view of the same operation. These are opportunities to make a product more valuable.
LiveUI changes how a product delivers its screens. The server describes the interface; a reusable client assembles it from a catalogue of components. Tables, maps, charts, forms and navigation become part of a shared screen language.
This is server-driven UI: a way to bring the interface closer to the business logic that shapes it. Teams can introduce new combinations of supported components through the backend, with the same client displaying the result.
For a software portfolio, that opens up an attractive possibility: invest in a common capability, then use it to create distinct experiences for different products, customers and roles.
Put reusable screen infrastructure underneath the roadmap, so teams can focus on the workflows that make their product valuable.
Publish new screen compositions centrally and let connected clients pick them up.
Give a dispatcher, maintenance planner and executive a workspace shaped around the decisions each needs to make.
One investment in how screens work.
Many possibilities for what your products can become.
02 / LiveUI meets Generative AI
Ask a language model for an interface and it will normally write code. Generated UI takes the other route. One request goes out, one structured document comes back, and that document can only describe a screen in the product’s own vocabulary.
That single decision is what makes a generated interface something a product can ship. It is also what makes the capability portable: the expensive half is built once, and each product supplies a description of its own data.
A business request in plain language, typed by the person who needs the view.
The model fills a strict form: a layout, the sections, and the data source behind each one.
The server checks the plan, fills the sections from the product’s data, and the screen goes to work: choose an asset and the other sections answer.
What the model chooses from
Fields the contract does not have
codehtmlscriptstyleurlsrchref
Every object in the schema is closed, so the model cannot add a field of its own. It never names a component either. It picks a value from a list, and server code turns that value into one of the 142 component types the client already ships.
What the server returns
| type: “iframe” | → | section dropped |
| 40 sections | → | 16 |
| 30 rows in a section | → | 10 |
| 20 columns | → | 6 |
| 1 000-character text | → | 420 characters |
| layout: “evilLayout” | → | verticalSplit |
| key: “DROP TABLE; ../../etc/passwd” | → | drop-table-etc-passwd |
| layout nested 8 deep | → | branch removed, sibling kept |
The server does not render the answer it received. It rebuilds the screen field by field. The rows above are what came back when the compiled server was handed those answers, on 12 September 2026. Model text is drawn as text by the client, never as markup.
The schema is the first gate and the server is the second. Between them, the shape of a generated screen is settled by the product rather than by the sentence someone typed — which is what turns an impressive demonstration into something a customer can be given.
Provenance, built in
A generated screen carries its own record. The line above the screen names the model and counts the sections the server filled from product data. Each section header repeats it: the catalogue key that supplied the rows, or model for the words the planner wrote itself.
An operator, an auditor and a support engineer all read the same screen and can tell, section by section, which numbers came from the business.
Status line: Generated by OpenAI model gpt-4.1-mini; 3 of 3 sections bound to the fixed Pit 3 demo snapshot.
A working surface
A generated screen is not a picture of an interface. Press Focus beside a truck and the server holds that asset for the session. Every other section that carries it answers: the work orders narrow to that truck, the queue and the activity feed follow, and the status line counts how many answered. The table you chose from keeps every row and names the asset it is holding, so you can hand the focus to another truck at any time.
The focus lives in the session on the server, not in the browser. It outlives the screen it was taken on: reload the page, or ask for a different screen entirely, and the new composition arrives already holding the same asset. That is the simplest way to see that the interface really is server-driven.
Before: Generated by OpenAI model gpt-4.1-mini; 3 of 3 sections bound to the fixed Pit 3 demo snapshot.
After Focus: Focus on TRK-042: 1 section answered from the catalogue. The focus is held on the server, so it survives a reload and the next screen.
The vocabulary, the schema, the validator and the renderers are platform work. They do not change when another product adopts them.
A product connects its own data through one small interface. In this demonstration that description is a single file.
From there, every request is a new workspace: the same components, the same guarantees, the data of whoever asked.
“Show the Pit 3 haul fleet, idle trucks and open work orders in one view.”
Typed components, data-source references and action contracts give an assistant a structured way to express an interface, and give the product a way to check it. Widening what an assistant can compose is a matter of adding to that vocabulary: charts joined it the same way tables and maps did. OpenAI structured outputs and a TypeScript backend power this demonstration; the vocabulary, the validation and the renderers are the platform’s own.
03 / One foundation, many experiences
Separate what a screen means from the technology that displays it. That creates room to evolve the product and its client experiences independently.
The React and Flutter demonstrations share a backend screen contract. Publish a new screen in one, then refresh the other: the new interface appears through the same reusable clients.
A versioned JSON contract provides the common language. React and Flutter provide alternative rendering technologies. This separation is especially valuable when a portfolio spans web applications and mobile experiences.
The backend describes. The client renders.
Built for the decisions that matter
A mining supervisor wants the incident, the affected equipment, the available options and the impact on the shift. LiveUI can bring these perspectives together in a coherent operational interface.
The same pattern applies to logistics, field service, industrial operations and enterprise software: combine information around the work a person needs to do.
Bring maps, metrics and equipment context into the same view.
Present alternatives, priorities and the reasoning behind a decision.
Use forms, action contracts and progress views to connect people with business processes.
04 / Make it part of your product
LiveUI can be introduced as an embedded operational surface, a new module or a foundation for a new application. Your existing product gives it context; your APIs connect it to the business.
TypeScript libraries, JSON contracts and a host–renderer bridge give engineering teams a clear integration boundary. The full-runtime demonstration brings that approach into a working React application: the original Flutter surface handles the interface while the LiveUI server owns its state and actions.
Try the complete interaction
A vehicle record connects the queue, its editing form and its history. Change the owner, leave a handover note and save: the same information appears throughout the workspace. Run an inspection and follow its progress to completion.
Then publish server v2. A handover panel joins the interface, using the components already in the browser. The evidence console lets you compare the client checksum before and after: the screen changes while the client executable stays the same.
Your own browser workspace, with sample data and a fresh-start button. Screen recipes here are prepared examples; explore Generated UI for composition from a prompt.
A maintenance review, dispatch exception or customer-specific dashboard. Start where a better interface can make a meaningful difference.
Bring in the host application, data sources, identity and business services. Shape the components and styling around your product.
Carry the same approach into another role, another workflow or another product. Add AI composition wherever a tailored view helps.
Part of a broader technology family
LiveUI can work alongside ChronoState for operational history and temporal context, and PatternWorks for durable workflows. Together, they offer a path from understanding a situation to coordinating a response.
05 / Explore it for yourself
Start with a generated screen, follow a complete interaction in the full runtime, then explore the client demonstrations and operational catalogue. The Demo Launcher brings the demonstrations and example prompts together.
Preparing the demos in the background…
Explore a fleet or maintenance view composed from a business request.
Open Generated UI ↗02 / EVOLVEEdit a record, publish a new server-defined panel and verify that the client stays the same.
Try the full runtime ↗03 / EXPANDSee operational applications, maps, charts and typed inputs.
Browse the catalogue →A conversation worth having
LiveUI brings together a reusable UI foundation and a natural place for AI to shape the user experience. Start with one valuable workflow — and imagine where a shared capability could take the rest of the portfolio.