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
An interface that moves
with your business.
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 ↓From operational insight to a place to actMining operations
Evolve your productsBring new experiences to your existing systems.
Make AI useful on screenTurn business intent into a tailored workspace.
Build on a shared foundationReuse the approach across products and devices.
The LiveUI story
01 / The opportunity
Let software keep pace
with the people using it.
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.
Change at the speed of the business
Publish new screen compositions centrally and let connected clients pick them up.
A personal view of shared information
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
The model never writes code.
It fills in a form.
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.
01Describe the task
A business request in plain language, typed by the person who needs the view.
02Plan from the vocabulary
The model fills a strict form: a layout, the sections, and the data source behind each one.
03Build and bind
The server checks the plan, fills the sections from the product’s data and builds the screen from shipped components.
What the model chooses from
- layout one of 7verticalSplit · horizontalSplit · tabs · ribbon · panelWithPreview · opsShell · empty
- section.type one of 9textPanel · metric · table · list · grid · map · sequence · workflow · form
- section.dataSource one of 15pit3-haul-fleet · pit3-alerts · pit3-response-options · open-work-orders · crusher-2-queue · workshop-capacity · shift-activity · pit3-map · seven shift KPIs
- header / title 72 / 80 chars
- rows 10 per section
- actions 4 per section
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
Every section says where its data came from.
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.
01
Built once
The vocabulary, the schema, the validator and the renderers are platform work. They do not change when another product adopts them.
02
Described per product
A product connects its own data through one small interface. In this demonstration that description is a single file.
03
Composed per request
From there, every request is a new workspace: the same components, the same guarantees, the data of whoever asked.
A request. A different perspective.
THE REQUEST
“Show the Pit 3 haul fleet, idle trucks and open work orders in one view.”
Try Generated UI ↗Open the app and choose an example, or describe your own view.
An AI interface with a product’s vocabulary.
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. 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
A shared language.
A choice of clients.
Separate what a screen means from the technology that displays it. That creates room to evolve the product and its client experiences independently.
Publish a screen once. Reach another client.
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.
Your business logicOne screen contractLayout · data · interactions
RReactWeb experience
FFlutterCross-platform experience
The backend describes. The client renders.
Built for the decisions that matter
From a sea of data
to a useful workspace.
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.
See the situation
Bring maps, metrics and equipment context into the same view.
Compare the options
Present alternatives, priorities and the reasoning behind a decision.
Follow the work
Use forms, action contracts and progress views to connect people with business processes.
04 / Make it part of your product
Start with one experience.
Build on what you own.
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. A React host can also embed a Flutter Web surface and exchange structured events.
Explore the React + Flutter embedding showcase ↗Choose a valuable moment
A maintenance review, dispatch exception or customer-specific dashboard. Start where a better interface can make a meaningful difference.
Connect your context
Bring in the host application, data sources, identity and business services. Shape the components and styling around your product.
Reuse and extend
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
From trusted context to coordinated action.
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.
ChronoStateUnderstand the state
PatternWorksCoordinate the work
LiveUIBring people into the loop
Built on familiar technologiesTypeScriptReactFlutterJSON contractsOpenAIAWSMapbox
05 / Explore it for yourself
Take the next idea
for a test drive.
Start with a generated screen, see a backend update reach two clients, then explore the operational catalogue. The Demo Launcher brings the demonstrations and example prompts together.
Preparing the demos in the background…
01 / CREATE
Ask for a screen
Explore a fleet or maintenance view composed from a business request.
Open Generated UI ↗02 / EVOLVEPublish a new experience
See a shared backend deliver a screen to React and Flutter.
Explore the client demos →03 / EXPANDExplore the possibilities
See operational applications, maps, charts and typed inputs.
Browse the catalogue →A conversation worth having
What could your product do
with a more adaptable interface?
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.