Why 5ms Is the Line Between a Safety System and a Logging System
The physics of intervention latency — why cloud-based safety architectures are fundamentally incapable of protecting humans at the point of action, and what the numbers actually mean.
Every safety system in the physical world makes a silent promise: I will stop the bad thing before it happens.
Most of them are lying.
Not out of malice. Out of architecture. The dominant paradigm in industrial safety AI is cloud-connected inference: sensors collect data, stream it to a server, run a model, return a decision. This works beautifully for dashboards. For retrospective analysis. For scheduled maintenance alerts. It fails catastrophically for the one thing physical safety actually requires — real-time intervention at the point of action.
Here is why the numbers matter.
The Physics of Harm
A MIG welder moving at standard travel speed covers roughly 8–12mm per second. A surgical drill in cortical bone advances 0.5–2mm per second. A mining haul truck's hydraulic arm, under load, can move 300mm in a single second.
Now consider the chain of events in a cloud-inference safety system:
| Step | Typical latency |
| Sensor capture + encoding | 5–15ms |
| Network transmission (LAN) | 2–8ms |
| Server queue + model inference | 40–200ms |
| Return signal + actuator response | 5–20ms |
| Total round-trip | 52–243ms |
At the high end — 243ms — you are not running a safety system. You are running a very expensive post-incident report generator.
The 5ms Mandate
Averiom's architecture is built around a single non-negotiable constraint: the sensing-to-inhibition loop must complete in under 5 milliseconds. This is not a marketing number. It is derived from the physics of the domains we operate in.
5ms at welding travel speed: < 0.06mm tool movement before intervention.
5ms in composites layup: intervention occurs before the fibre stack is displaced.
5ms in mining equipment: hydraulic force redirection before the torque threshold is breached.
To achieve this, every component of the system is designed for the edge:
Sensor fusion runs on-device at 1kHz. No network hop. Raw IMU, force, and vision data fused locally using a Kalman filter stack — the same mathematical framework used in aerospace inertial navigation, chosen because it provides optimal estimates under Gaussian noise without requiring a cloud backend.
The Prediction Kernel does not ask "is this wrong?" It continuously evaluates the Negative Manifold — the 3D boundary of the failure region — and forecasts trajectory 150–300ms into the future. By the time a violation occurs, the system has already been intervening for 150ms.
The Inhibition Engine executes tiered physical response: haptic warning, then viscous damping (resistance force proportional to proximity to boundary), then hard lock via solenoid actuation. The response is proportional — the system does not simply stop the operator; it communicates the danger through the tool itself.
What Cloud Safety Cannot Do
The argument for cloud inference is usually cost and flexibility. You do not need to put compute on every device; you amortise inference cost across the fleet; you can update models without touching hardware.
These are real advantages — for the wrong problem.
Physical safety is not a fleet-level problem. It is a point-of-action problem. The weld bead does not care that your cloud model is 97.3% accurate on your validation set. The weld bead cares what happens in the next 5 milliseconds, on this specific tool, in this specific material configuration, with this specific operator's micro-correction pattern.
There is a second, deeper problem: cloud-connected safety systems create a single point of failure at the network boundary. A momentary LAN dropout, a queue spike, a model redeployment — and your safety system is offline. In safety-critical environments, "offline" is not acceptable. The Averiom runtime has zero cloud dependency. Not "optional cloud." Not "cloud-enhanced." Zero. The edge device is the safety system. The cloud, if present, is for data aggregation and profile synchronisation — never for real-time control.
The Logging System Problem
Here is the uncomfortable truth about most industrial AI safety deployments: they are not safety systems. They are incident documentation systems.
They detect that something went wrong. They log it. They alert someone. They generate a report. All of this is valuable. None of it prevents the harm that already occurred.
The distinction matters enormously for liability. If your system logged a warning 180ms before the injury and the actuator response arrived 20ms after, your system did not fail to detect the problem — it failed to act on it in time. In an AS/NZS 4024-governed environment, that distinction will be examined carefully after an incident.
Averiom's evidence chain exists precisely to survive this examination. Every intervention is cryptographically signed and timestamped. The .avm profile records not just that an intervention occurred, but the exact sensor vector, the predicted trajectory, and the tier of response — all in under 5ms of the event. This is not retrospective logging. It is a contemporaneous, tamper-evident record of the system acting.
Where This Is Being Applied
We are currently exploring Averiom's universal safety architecture in two beachhead domains:
Mining equipment — hydraulic arm control systems in autonomous and semi-autonomous haul trucks and excavators, where boundary violations under load carry multi-tonne force consequences. We are working towards design partnerships with operators in the Queensland mining corridor.
Composites welding and related trades — precision welding on composite structures where sub-millimetre control is a quality and safety requirement simultaneously. We are exploring this in collaboration with the Australian Manufacturing Capability Network (AMCN) and working towards partnership with the Australian Manufacturing Growth Centre Ltd (AMGC).
Both domains share the same underlying constraint: the cost of a boundary violation is measured in irreversible physical outcomes. That is exactly where 5ms is not an engineering preference — it is a requirement.
If You Are Building Safety-Critical Systems
The question to ask your current or prospective safety vendor is simple: what is your end-to-end sensing-to-actuation latency, and where in that chain does network I/O occur?
If they cannot answer the first question with a specific number, they are not a safety system.
If the answer to the second question is "between sensing and actuation," they are not a safety system for physical environments.
We are looking for design partners who understand this distinction and are ready to build the right thing. If that is you — reach out.
Related: The Cage Problem — why exclusion zones are the ceiling on industrial automation · ICL explained — the technical mechanism behind the Negative Manifold · Peer-reviewed paper: Springer CCIS · HCII2026
We are seeking design partners in autonomous mining equipment and composites welding, and investors who understand the foundational infrastructure opportunity in physical AI governance. Supported by the Australian Government Industry Growth Programme and in discussions with AMCN and AMGC.