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, bind and respond

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

  • layout one of 7verticalSplit · horizontalSplit · tabs · ribbon · panelWithPreview · opsShell · empty
  • section.type one of 11textPanel · metric · table · list · grid · map · sequence · workflow · form · barChart · pieChart
  • 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 sectiona chart section takes the same rows and draws the numeric column
  • 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

A working surface

The screen answers back.

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.

TRK-023 in focus · the header names it and the row offers Clear
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. 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

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. 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

Change the work.
Keep the client.

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.

One connected application. React host · original Flutter renderer · server-owned interaction.Open the live workspace ↗
  1. Edit and saveSee a record change across the form, details and history.
  2. Change the serverPublish v2 and compare the client checksum in the evidence console.
  3. Reshape the viewChoose Shift handover in the React host, try the read-only profile and resize the window.
Try the full runtime ↗

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.

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, 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…

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 ↗