In short
A plant describes itself in three forms that never share a language: sensor data, documents and drawings.
A large language model on its own gives fluent answers, not engineering decisions. It is built to predict text, not to reason over dense sensor data or respect a mass balance.
Applied Computing splits the problem in two: a world model for energy that understands the plant, and a system around it that assembles and checks the evidence for each decision.
What would it take for an AI system to take part in an industrial decision? Not to write a paragraph, and not only to predict a number. To take part in a decision, it has to be grounded in the same plant the engineer is reasoning about: a live process that never stops, and does not pause while the data is cleaned.
What is a world model for energy?
A world model for energy is an AI model that learns how an industrial plant behaves, from its operating data, its physics and its engineering knowledge, so it can predict what happens next and what would happen if something changed. It is a form of physical AI: AI that reasons about how the physical world behaves, not only about text or images. At Applied Computing, the Orbital world model is the foundation of Orbital, our AI for plant operations.
This series follows one idea from the plant floor to a shift decision. This first part starts with what a plant leaves behind of itself, and why a general-purpose language model on its own falls short. For the wider case, see why refineries need applied AI rather than general AI.
What data does an industrial world model learn from?
An industrial world model learns from the three records every plant keeps of itself: time series from its sensors, the documents its engineers write, and the drawings that show how it is built.
Three records of the same plant
Sensor data. Time series from the plant historian. Thousands of tags per unit, often sampled every minute, with years, sometimes decades, of history. It records how the plant behaves.
Documents. Operating manuals, shift logs, incident reports and datasheets, written by engineers for engineers. They record intent and experience.
Drawings. Piping and instrumentation diagrams (P&IDs) and process flow diagrams. They record the plant's structure: which equipment connects to which, and where each instrument sits.
All three describe the same plant, but they do not share a language. A temperature tag in the historian, a paragraph in the operating manual and a symbol on a P&ID can all refer to the same reactor, and nothing in the data says so.
The volume matters too. A large site with around 15,000 instrument tags, read once a minute, produces more than 21 million readings a day from sensors alone. That is far more than today's largest language models can take in at once, and it is before a single document or drawing is added.
What does answering one engineering question involve today?
Answering one engineering question well usually means crossing several systems that do not talk to each other, and most of the effort goes into building context rather than optimising. Take a question an engineer might ask on any shift: why is coke laydown rising on the reactor this week?
The workflow behind one engineering question
Pull the data. Find the right tags for the unit and the right time window.
Clean and reconcile. Deal with gaps, bad sensors and lab results that arrive hours late.
Check limits. Compare the operating point with equipment and quality limits.
Find the cause. Trace the change back through the process to its source.
Run scenarios. Test the possible responses.
Cost the change. Weigh energy, throughput and quality against each other.
Write it up. Document the reasoning so others can review it.
Change the set point. Make the change through the normal operating procedure.
The optimisation itself is one small step in the middle. Most of the engineering work is building enough context to trust that step.
Why can't a large language model optimise a process plant on its own?
Because a large language model is built to predict text, not to reason reliably over dense numerical time series or to respect a mass and energy balance. Asked the coke question on its own, it usually gives an answer that is fluent and plausible: several variables appear correlated with coke laydown, reactor severity may be elevated, consider reviewing feed quality with site engineers.
Fluent, plausible, and not a decision. No numbers, no mechanism, no evidence.
Nothing in that answer is wrong, exactly. But an engineer cannot act on it. It does not say which tags moved, by how much, what the physics allows, or what to change. It sounds like an answer without doing the work of one.
Language models are still useful in industry. They read documents well and explain results in plain words. The problem is relying on one alone. A plant decision needs a model grounded in the plant's own data and physics, with language as one input rather than the whole answer.
Why split the problem in two?
Because understanding the plant and reaching a decision are different technical problems, and they fail in different ways. Our approach separates them.
A world model that understands the plant well enough to stay useful when sensors go missing and when the question changes.
A system around it that assembles and checks the evidence a particular decision needs, and is honest when there is not enough of it.
A good model behind a dashboard still leaves all the work of reaching a decision with the engineer. A clever system wrapped around an ungrounded model can run many steps and still be wrong. The rest of this series takes each half in turn: what a world model for energy is and how it reads the plant, why physics has to be part of how it learns, and how Orbital turns a question into a decision.
Frequently asked questions
Why can't large language models optimise a process plant?
Large language models are built to predict text. On their own they are not designed to reason reliably over millions of sensor readings a day, or to respect mass and energy balances and equipment limits. They can produce fluent, plausible answers that contain no numbers, no mechanism and no evidence an engineer can act on. A plant decision needs a model grounded in the plant's own data and physics.
Are language models useless in industry?
No. Language models are good at reading documents, searching procedures and explaining results in plain words. The problem is relying on them alone for operating decisions. A plant decision needs a model grounded in the plant's own data and physics, such as a world model for energy, with language as one input rather than the whole answer.
What is a world model for energy?
A world model for energy is an AI model that learns how an industrial plant behaves, from its operating data, its physics and its engineering knowledge, so it can predict what happens next and what would happen if something changed. Applied Computing's Orbital world model is the foundation of Orbital, its AI for plant operations, which helps engineers detect, predict, optimise and simulate.
How much data does a process plant produce?
A large site with around 15,000 instrument tags, read once a minute, produces more than 21 million sensor readings a day. Many plants keep years, sometimes decades, of this history. That is before shift logs, operating manuals, incident reports and engineering drawings are counted, all of which describe the same plant in different forms.
About the author
Applied Computing research team
Applied Computing
The engineers, data scientists and AI researchers building the world model behind Orbital.
