A process world model is built once for a kind of operation: its physics and domain knowledge generate millions of simulated worlds, and one network is pretrained on them. It then reads a site's own data, live or recorded, and answers what happens if you change something, and why. This page is the technology; the domain pages show it at work.
Most operations already have twins and simulators. Each answers a different question. A process world model sits on the top rung: not just mirroring the operation or forecasting it, but telling you which action will change the outcome, and why.
What is installed: the units, their sizes and how they connect. It sets the capacities and how long material or work takes to pass through.
The flowsheet: digester, washers, evaporators, recovery boiler, kiln, paper machine, and the tanks between them.
The layout: aisles, shuttles and lifts, conveyors, pick stations and buffer lanes.
The hardware: GPUs per node, memory per GPU, and the links between GPUs and between nodes.
What comes in. A change here often shows up hours or days later, further down the line.
Wood species and moisture, recycled fiber, chemicals.
Orders and inbound pallets: how many, how big, and when in the day they arrive.
The model being served and its traffic: prompt and answer lengths, requests per second.
How the operation is actually run: automatic control and people’s habits. It is why history alone can mislead.
DCS loops, advanced control, and how each crew runs its shift.
The warehouse control system’s rules: which order goes first, where a tote is stored, when a shuttle charges.
The serving engine’s scheduler and the autoscaler: which request runs next, when to add a replica.
The knobs you can turn. These are what Recommend searches over.
Press load, steam pressures, chemical charges, refining energy.
Wave size, slotting, shuttle speed limits, buffer sizes, staffing per shift.
Parallelism, precision, batch size, cache size, and which engine.
What the operation must deliver: specs, rates and prices. The same equipment is easy or hard to run depending on them.
The grade slate: basis weight, moisture, strength, tonnes per day.
Orders shipped by the cutoff, lines per hour, cost per order.
Time to first token, tokens per second per user, cost per million tokens.
Given every setting and condition, it computes what happens, step by step. Written from physics and domain knowledge, not fitted to your data.
Chemistry and heat: mass and energy balances, cooking and drying, unit by unit.
Queues and travel times: how long each move takes, where work waits, how buffers fill.
Compute and memory: how long each step of the model takes on each chip, and how requests queue.
The forward model, run across everything that differs from one site to the next, so that every simulated world is different.
Mills differ in wood, equipment condition, sensors and how they are run.
Warehouses differ in layout, equipment condition, order patterns and how they are run.
Clusters differ in hardware, software versions, traffic and how they are run.
Millions of simulated worlds, each one a different site, run for weeks.
Millions of simulated mills, each run through weeks of production.
Millions of simulated warehouses, each run through weeks of orders.
Millions of simulated serving setups, each under its own traffic.
One network learns, across all the simulated worlds, how sites behave and what changes do. Paid once, by us, before any customer asks a question.
One network for mills. No modeling project per mill.
One network for warehouses. No simulation study per site.
One network for serving. No benchmark campaign per model and GPU.
The trained network, one per domain. Every question is one pass, answered in seconds, for sites it has never seen.
Answers for your mill on day one, from the history you already keep.
Answers for your warehouse without building a simulation model of it.
Answers for any open model on any hardware, including hardware you have not bought yet.
What you ask: a change, a goal, a choice of equipment, or a plan over time.
“Raise press load 5%: what happens to steam use and strength?”
“Add two shuttles to aisle 4: do we make the 6 pm cutoff?”
“GLM-5.3-Flash on 4× H200: cheapest setup at 10 tokens per second per user?”
What the site already records. It tells the model which simulated world is yours.
Historian tags, lab results and shift logs.
Warehouse and control-system logs: orders, moves, faults and downtime.
Serving metrics and GPU telemetry, or an optional 5-minute benchmark.
The forecast, the recommended setting and how sure the model is.
Press load +5%: steam −4% (± 1), quality held.
Two more shuttles: cutoff met on 96% of days (± 2).
TP4 · FP8 · batch 64: 31 ms per token (± 3), $0.42 per million tokens.
When the site does not do what was forecast, find the cause and fix the world model, not the number.
Steam came in above forecast: an evaporator effect was fouling.
Throughput fell short: one lift kept stopping on the same fault.
Slower than forecast: a driver update changed how fast one kernel runs.
Other kinds of model learn a system's dynamics from its data. A process world model learns to infer from written physics, which is why it works where history is thin and why it can answer what a change would do.
The forward model is written from balances, rates and known behavior. It generates the training worlds, so the model has seen far more situations than any one site's history contains.
A written process model is a causal model: its mechanisms are stated. Asking what a change would do is a question it was trained to answer, not a correlation it has to stretch.
The model reads a site's history and recognizes which simulated world it is in, instead of being tuned by hand for each site.
Measurements from real sites are used to test the model on held-out cases. They are never used to fit it, so a good score means the physics is right.
When a site does something the forecast missed, the causal model names the cause, the missing mechanism goes into the physics, and the model is retrained. Numbers are never patched to fit.
Physics-informed networks put the equations in the loss of one model fitted to one dataset. Here the physics is the prior that generates millions of worlds, and the network is trained once on all of them.
Each domain gets its own forward model and its own trained network. They share the machinery, not the physics.
Know what a setpoint change will do before you make it, from your mill's own history.
Pulp & paper →Setup, speed and cost for the models you serve, on any hardware, with a live demo.
NeoClouds →What drives faults, downtime and throughput, read causally from the system's history.
Warehouse →Your operation is not on this list? Build its process world model with PFN Studio →
Tell us what you want to model and we will be in touch.