Safety policies are not a risk assessment

Every industrial robot installation has a risk assessment. It is thorough, it was written by someone competent, and it lives in a binder or a PDF nobody has opened since commissioning. Meanwhile the code does whatever the code does. Nothing in the normal course of events checks that the second still matches the first — and that gap, not the quality of either document, is where most surprises come from.

Two artefacts that should be one

The risk assessment says: in this cell, at this speed, with this guarding, with these foreseeable misuses considered, the residual risk is acceptable.

The control software says: move there, at that speed, unless this input is high.

They describe the same system and they are written in different languages, by different people, at different times, and only one of them is executable. When the machine’s behaviour and the paperwork diverge, the machine wins — silently.

The three ways they drift apart

Parameter creep. A speed limit is raised for a legitimate reason during a busy week. The change is real and immediate; the paperwork’s version of that limit is not updated, because updating it is a separate process owned by someone else.

Environmental change. New racking, a rerouted walkway, a new product with a different footprint. The assessment described a layout that no longer exists. Nothing about the software noticed, because the software was never told what the layout was for.

Personnel change. The engineer who knew why a particular limit was set that way has moved on. The limit survives as a number with no reason attached, which means the next person to find it inconvenient will change it.

What policy-as-code actually fixes

Writing the envelope as versioned, testable data does not replace the risk assessment. It gives the assessment something to bind to.

The reason lives with the rule. A limit carries a comment, an author, a date and a reference to the assessment clause it implements. The next engineer finds the reason attached to the number instead of having to look for it.

Changes are reviewable. Adjusting what a machine may do becomes a diff with a reviewer, not an edit to a running config. That single change turns “somebody raised a limit” from an archaeological question into a line in a history.

Divergence is testable. You can replay a month of recorded operation against the envelope and see whether the machine ever came close to a boundary the assessment assumed it could not reach. That converts an annual document review into a continuous check.

Refusals become data. Every time the harness stops something, that is evidence about the gap between assumed and actual operation. A rising refusal rate in one zone means the assessment’s picture of that zone is out of date — and you learn it in weeks rather than at the next audit.

What this does not do

It does not certify anything, it does not satisfy a standard by itself, and it does not replace the judgement of a safety engineer. The obligations that come with putting machinery near people — assessment, guarding, safety-rated control, validation — sit exactly where they sat before, and the relevant standards say who has to do what.

What it does is close the loop between the document and the machine, so that the assessment stops being an artefact of commissioning and becomes something the system continuously demonstrates it still complies with.

The question worth asking

At your next review, ask one thing: can you show that the machine’s current limits match the ones the assessment assumed?

If the answer requires someone to open a controller, read parameters and compare them by hand against a PDF, that is the finding. Not because anybody did anything wrong, but because a check that expensive is a check that will not be repeated — and an unrepeated check is a belief, not a control.