Sim to real transfer is the problem of moving a controller that works in simulation onto the physical system it was meant for, and discovering what the simulator left out. Almost everything written about it is written about robots. Manipulators, quadrupeds, quadrotors: platforms that reset in seconds, run at kilohertz, and can be instantiated a thousand times on one GPU.
That is not the setting most industrial control lives in. A distillation column, a gasifier or a cultivation basin runs on hours or weeks, cannot be reset, and is observed through proxies rather than encoders. The formalism from robotics still holds. The methods built on top of it mostly do not, and it is worth being specific about which parts survive the move.
What the reality gap is, stated precisely
The clearest statement of the problem comes from a 2026 survey of the reality gap in robotics. Treat the system as a partially observable Markov decision process. A simulator approximates two of its components: the transition dynamics, which say how the state evolves under an action, and the observation model, which maps the latent state to what your sensors report. Perfect fidelity is impractical and computationally infeasible given friction, noise and latency, so both approximations carry error.
That gives the useful decomposition. The reality gap is not one quantity. It is at least two: a dynamics gap, the divergence between simulated and real transition dynamics over the states you actually visit, and a perception gap, the divergence between simulated and real observation models. Which one dominates decides which method is worth paying for, and teams routinely buy a solution for the wrong one.
The reality gap is not the performance gap
The same survey separates a second thing that is easy to conflate. The performance gap is the absolute difference in expected return for a specific policy between simulation and reality. The reality gap is a property of the two environments; the performance gap is a property of a policy running in them. They move together but they are not the same, and the practical consequence is liberating: exact replication of real dynamics is neither achievable nor required. A large reality gap with a small performance gap is a successful transfer. You are not trying to build a perfect simulator. You are trying to build a policy that does not care about the difference.
The failure case is worth naming because it is the one that ends projects. A survey on crossing the reality gap for robot controllers puts it plainly: the most undesirable result is a controller learnt in simulation that fails the task on the real machine. Simulation performance is not evidence. It is a hypothesis.
Why the robotics playbook does not port to a live process
Four structural differences, and each one invalidates a method that the robotics literature treats as standard.
Resets and parallelism are assumed away. The premise of the whole field, stated in a review of robot learning from randomized simulations, is that generating data on a physical platform is prohibitively expensive while simulation is fast and cheap. True for a plant too, but the asymmetry is far more extreme: a robot arm gives you a hundred real trials in an afternoon, and a grade transition on a reactor gives you perhaps a dozen in a year.
Timescale changes what a trial costs. A bad action on a manipulator is visible in milliseconds and reversible in seconds. A bad setpoint on a thermochemical process is visible in tens of minutes and may not be reversible at all in the current campaign. A crashed culture restarts on the same timescale as the growth it interrupted.
The disturbances are not parametric. This is the important one. Domain randomisation, as catalogued in a deep dive into zero-shot transfer for dynamic tasks, randomises physical parameters such as mass and friction, control parameters such as actuator gains, time delays and observation noise. Every item on that list is a number the simulator already has. Work on sim-to-real transfer for non-steady-state control of chemical plants names a different set of gap sources: modelling errors, incorrect state identification, and unpredicted disturbances on the real situation. Its worked example is heavy rain, and the reason it cannot be randomised is stated directly: such situations are usually unmodelled on the dynamic simulator, because the measurements needed to reproduce them, rain gauge, aerovane, heliograph, are generally unavailable.
And the tolerance for exploration is lower. Research on transfer learning for process control makes the comparison explicitly: safety and stability demands in the process industry are higher than in finance, recommendation or robotics, and that, combined with extremely low sample efficiency, is why deep reinforcement learning has struggled to reach industrial deployment. The energy-systems literature says it more bluntly still. Work on Sim2Real transfer for organic Rankine cycle superheat control opens by noting that direct application of deep reinforcement learning to a physical ORC system presents unacceptable safety risks and that its generalisation under model-plant mismatch is insufficient to support the control requirement.
Domain randomisation and the assumption underneath it
None of that makes randomisation wrong. The canonical result, sim-to-real transfer of robotic control with dynamics randomization, still stands: randomise the simulator dynamics during training and the resulting policies adapt to dynamics very different from the ones they saw, generalise to a real robot with no training on the physical system at all, and stay robust to significant calibration error. If your mismatch is parametric, this is cheap and it works.
The assumption is in the first word. You can only randomise a parameter you have named. So the diagnostic is short: write down the five things most likely to differ between your simulator and your plant, then check how many of them are numbers in the simulator at all.
On a thermochemical or biological process the list usually comes back as feedstock composition, heat-exchanger fouling, ambient conditions, and a slow drift in a state nobody measures directly. Only the first is reliably a parameter. Randomising the three you have while the two that matter sit outside the model produces a policy that is robust to the wrong things, and the confidence interval it reports is measuring your simulator rather than your plant.
Closing the gap from both sides
The chemical-plant work cited above proposes the alternative, and it is the most instructive published deployment near this keyword. Rather than making the policy robust to the gap, it attacks the gap bidirectionally: bring the simulator to the plant, and bring the plant to the simulation.
The control problem is split into three tasks, each assigned to a separately trained agent and integrated afterwards. The first identifies model parameters and current state, adjusting the simulation until it reproduces the real situation. The second optimises the non-steady operating procedure from that identified starting point. The third rejects disturbance, adjusting control inputs so the real trajectory tracks the simulated and predicted one. Two details deserve attention from anyone planning a deployment. The identification agent is interpretable as an offline-optimised particle filter, which moves the expensive search out of the online loop, an argument about compute placement rather than accuracy. And the generated procedure is reviewed and authorised by human operators before it is applied to the plant, one step at a time. The learned component proposes; it does not acquire authority. That was validated on an actual binary distillation plant separating methanol and water, under an emulated heavy rain disturbance.
The MDP is the transfer decision, not the algorithm
Before the algorithm, the problem formulation. A 2026 study on the impact of Markov decision process design on sim-to-real transfer is unusual in ablating design choices rather than methods: state composition, target inclusion, reward formulation, termination criteria and the environment dynamics model, evaluated in simulation and then on physical hardware. Its headline result is the one to carry into a project. Physics-based dynamics models achieved up to 50 percent real-world success under strict precision constraints, in a setting where simplified models failed entirely.
Read that carefully, because it contradicts the intuition most teams start with. Simulator fidelity does not degrade gracefully. A simplified model does not give you a slightly worse policy; under a tight tolerance it gives you nothing. Fidelity behaves like a threshold, and the threshold is set by the precision the process demands rather than by the modelling budget.
That is the argument for deriving the equations of the process before building anything on top of them, and for treating the state model as the deliverable it is. Where the process is measured irregularly and at multiple rates, which is the normal condition for a plant with mixed online analysers and lab assays, continuous-time models built for irregularly sampled process data are the tool for that state model rather than a resampled fixed-step approximation.
What you deploy is a stack, not a policy
Transfer does not finish at the policy weights. If a gap remains, and it does, something has to handle it at runtime.
The cleanest recent demonstration comes from safe deployment of offline reinforcement learning on an exothermic polymerisation reactor. Training offline from historical operating data removes the unsafe-exploration problem entirely, but it introduces a different one: the baseline offline agents show steady-state offsets and degraded performance near setpoints, which is a plain description of a policy that is right about the shape of the problem and wrong about the last few percent. The proposed answer is a deployment-time layer that corrects the action by descending a learned convex, state-conditioned cost surface, with no retraining and no environment interaction.
The general lesson is architectural. Whatever gap the policy carries, correction happens at deployment, and the correction layer is a component with its own requirements. Where the correction has to be a guarantee rather than an adjustment, a control barrier function turns that correction into a hard constraint, and the wider set of obligations is covered in what has to be proven before a learned policy moves a valve.
Whichever form it takes, it has a latency budget. A correction layer that answers slower than the process moves is documentation, not a control element. The figures from our own control stack are a safety layer answering in under 2 ms against an end-to-end edge path of 285 ms, reduced from 1.2 seconds. The 285 ms number was not a hardware upgrade; it came from compressing the model until it fits the latency budget, which is the work that makes a runtime correction layer implementable at all.
What a transfer record has to contain
The last question is how you know the transfer happened, and the honest answer is that you know it from the record, not from the first successful run.
Ours, on the control side, reads as follows. Growth-model accuracy at R-squared above 0.95. Validation on a 500 L pilot basin with zero safety violations across 400 simulated years. The simulated years are the part to read carefully, and we state what they are: coverage of the state space, not elapsed operating time. Four hundred years of a simulator agreeing with itself proves nothing on its own. What makes coverage into evidence is the surrounding structure. On the OptiVX programme, 29 accounted work phases with 400 simulated years certified and a 31 percent yield increase. On IntelliBot, predictive validation across four workstreams with 8-node horizontal scaling and over 400 pages of transfer documentation.
Those pages are not overhead. They are the deliverable that makes the result usable by somebody who was not in the room, which is what separates a contract research programme from a demonstration, and what a funding body or a certification reviewer will actually read.
So the criterion is this. You have not transferred a controller when it runs on the plant. You have transferred it when you can say, in advance and in writing, which states it was tested in and which states it was not.
FAQ
What is zero-shot sim-to-real transfer?
Deploying a policy trained entirely in simulation onto the real system without any further training on task-specific real-world data. It is the strictest form of transfer, and most of the reported successes are vision-based tasks with relatively simple underlying dynamics, generally built on domain randomisation. Where the dynamics are complex, zero-shot transfer is much harder, and that holds even when the vision problem is removed by using fiducial markers.
How accurate does the simulator have to be?
Not perfect, and perfection is the wrong target: exact replication of real dynamics and observation models is neither practically achievable nor required, because transfer succeeds when the policy is robust to what remains. But fidelity is not a smooth dial either. On a task with strict precision constraints, a physics-based dynamics model reached up to 50 percent real-world success where simplified models failed entirely, so there is a floor below which the simulator buys you nothing at all.
Is domain randomisation enough on its own?
It is enough when the mismatch is parametric and you can name the parameters. Randomising mass, friction, actuator gains, delays and observation noise has produced policies that transferred to real hardware with no physical training and tolerated significant calibration error. It stops being enough when the discrepancy is an unmodelled, time-variant disturbance for which the simulator has no parameter, which is the ordinary case on a process plant.
Can I use historical plant data instead of building a simulator?
Partly. Offline reinforcement learning trains a policy from historical operating data with no online experimentation, which removes the exploration risk that makes direct training on a live plant unacceptable. The cost appears at deployment as steady-state offsets and degraded performance near setpoints, so the workable architecture pairs the offline policy with a runtime correction layer rather than shipping it alone.
Who signs off before the policy touches the plant?
In the one published sim-to-real deployment on a real chemical plant, a human operator does. The procedure is generated and its consequences predicted on the simulator, then reviewed and authorised, then applied a step at a time while a separate agent corrects for the gap as the operation runs. That sequence is worth copying: it makes the learned component a proposer rather than an authority, which is also the easiest version to certify.