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
A connected operating experience. Live Operations product concept.Explore the concept ↗
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.

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.

01

More room for product innovation

Put reusable screen infrastructure underneath the roadmap, so teams can focus on the workflows that make their product valuable.

02

Change at the speed of the business

Publish new screen compositions centrally and let connected clients pick them up.

03

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 sections16
30 rows in a section10
20 columns6
1 000-character text420 characters
layout: “evilLayout”verticalSplit
key: “DROP TABLE; ../../etc/passwd”drop-table-etc-passwd
layout nested 8 deepbranch 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.

Generated fleet review · each header names the catalogue source behind the section
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.”

Generated fleet review · three sections, three catalogue sourcesClick the image to explore
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.

The same idea, in a different space. Generated UI at desktop and phone sizes.Explore both views ↗

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.

LiveUI operations cockpit · Pit 3 scenarioExplore operational applications ↗

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 ↗
01

Choose a valuable moment

A maintenance review, dispatch exception or customer-specific dashboard. Start where a better interface can make a meaningful difference.

02

Connect your context

Bring in the host application, data sources, identity and business services. Shape the components and styling around your product.

03

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…

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.

Revisit the adoption path ↑

Selected LiveUI screenshotOpen full image ↗