Software can be rolled back. A forklift cannot

Inside a warehouse management system, a bad decision is a bad row. A pallet is assigned to the wrong location, someone notices, the record is corrected, and the only cost is a little confusion. Software engineering is built on this: transactions, rollbacks, version control, undo. Almost every mistake can be taken back.

Now send the same decision to an autonomous forklift. The pallet is lifted, carried down an aisle and placed on a rack. If the location was wrong, there is no rollback. Undoing the move means making another move, with its own risks, in a world that has changed while the first one was happening. And if the rack was the wrong one because it was already at its rated load, the mistake is no longer about data at all.

Why the physical boundary changes the problem

A business that only manipulates records is not autonomous; somebody still has to load the truck, which is why physical execution is one of the six components on the Demertis homepage. But the moment the loop reaches machines that move things, three assumptions that software relies on stop holding: that actions can be reversed, that the system’s picture of the world is current, and that nobody is standing in the way.

What changes at the edge of the machine

Actions are irreversible. A movement has no inverse, only a compensating movement. That makes “try it and roll back if it fails”, the default habit of software, unavailable for anything that touches the physical world.

The world model is always late. Sensors report with a delay, and positions change during an action that takes seconds. The loop decides on a snapshot and acts in a world that has moved on. Any design that assumes the snapshot is still true at the moment of action will eventually be wrong at that moment.

Safety cannot live in the decision layer. The planner that decides where pallets go, perhaps a learned model, perhaps a large optimiser, must not be what keeps people safe. Safety functions belong in a separate layer, with its own sensors and controllers, that stops or slows the machine whatever the planner wants. The planner may request movement. It may never override a stop.

Stopping has a shape. A machine that loses power mid-lift is not safe because it stopped. Each machine needs defined stop states, from “finish this movement and hold” to “lower the load and cut power”, which is the physical side of what we wrote about an off switch the system cannot reach.

People are in the scene. Even a facility designed to run unattended has maintenance staff, inspectors, delivery drivers and, on a bad day, emergency services. The loop has to treat the presence of a person as a fact about the world, not as an exception.

The law already has a view

None of this is new territory for regulators. EU rules on machinery safety increasingly deal with machines whose behaviour can change over time, and those on artificial intelligence look more closely at AI systems that play a part in keeping such machines safe. Industry standards for driverless industrial trucks describe how the safety layer itself is expected to behave. What applies to a given machine depends on what it is and how it is used, and is worth checking with someone who knows the sector. An autonomous operation does not get to treat any of this as optional because its decisions are made by software.

Writing the safety case before the loop

Hazards first. For each machine the loop will reach: what is the worst thing it can physically do, where can people be, and what stops it. This comes before any decision logic is connected.

Planner and safety layer stay separate. The planner sends requests through a boundary enforced outside it, which includes physical zones, speeds and loads. The safety layer can veto any request and never needs the planner’s agreement to do so.

Stop states are defined and exercised. Each level of stopping is tested on a schedule, in normal conditions, not saved for the day it is needed.

Record what was sensed, not only what was commanded. The ledger of a physical loop has to show what the machine actually did and what its sensors saw, because the command and the outcome can differ.

Widen the world in steps. Simulation, then a segregated cell, then shared space, with the safety case rewritten at each step. It is also why the physical loop appears on this programme’s roadmap as the next stage, in a controlled facility, rather than as something already running.

A test you can run today

Pick one automated action in your operation that touches the physical world: a dispatch to a robot, a conveyor diverting a parcel, a valve, a door, a dosing pump. Write down what undoing it would actually involve.

If undoing it means another physical action with risks of its own, ask two questions: who has checked that path, and when was it last exercised? If nobody can answer, the operation is relying on software habits in a place where they do not apply.