Safety Detection

Detecting a hazardous condition is the application with the clearest case. It is also where detection most often stands in for a barrier.

What works well

A person in a vehicle aisle or machine zone. Well-defined, visually obvious, high consequence.

A blocked fire exit or escape route. Static condition, easy to define, regulatory relevance.

A spill or obstruction on a walkway.

Missing protective equipment in a designated area, where the equipment is visually distinctive.

A vehicle exceeding a speed in a marked zone, where geometry allows estimation.

Each of these is a condition rather than a behaviour, which is what makes it definable and evaluable.

The hierarchy still applies

Eliminate the hazard. Remove the task, automate it, change the flow.

Substitute something less hazardous.

Engineering controls: barriers, interlocks, physical separation.

Administrative controls: procedures, scheduling, signage.

Detection sits below all of these, as a supplement.

A detector in an aisle that should have a barrier has bought a warning for a hazard that could have been removed, and it is cheaper and faster, which is why it wins.

Reporting it honestly

Name the primary control the detection is supplementing.

Record it as interim with a date for the physical work.

Put it on the risk register with that date, not as a closed item.

Report the count of interim measures past their date, which should be small and rarely is.

Without this the supplement becomes permanent and the barrier is never installed.

Real-time versus retrospective

Two different systems with different requirements.

Real time needs an operator, a response procedure, an acceptable alert rate and low latency. Without all four it is a logging system with an alarm noise.

Retrospective needs none of that and is genuinely useful: reviewing whether a condition recurred, investigating an incident, establishing a baseline.

Start retrospective. It establishes the true event rate, tunes the threshold against real data, and produces the evidence for whether real-time alerting is warranted.

Most deployments start real-time and discover the alert rate afterwards, which is the wrong order.

Reading the output as conditions

A cluster of detections at one location is a layout finding.

A cluster at shift change is a scheduling finding.

A cluster during one task is a method finding.

Investigate location and circumstance before person, every time, and say publicly that this is the policy.

Otherwise reporting degrades: if a detection produces a conversation about the individual, people work around the camera, and the data stops describing the hazard.

What to measure

Recall against ground truth, because a safety system that misses events is providing false assurance.

False alarms per operator per shift, which determines whether alerts are read at all.

Time from detection to response.

Detections by location and hour, which is where the preventive value is.

Incidents alongside detections. Falling detections with flat incidents means the system is being avoided rather than the hazard removed.

Starting retrospective

The sequencing decision that most improves the odds of a safety deployment working.

Run the detection without alerting for a period.

Collect what it finds and compare against ground truth.

Establish the true event rate, which nobody usually knows.

Tune the threshold against real data rather than a vendor default.

Compute the alert volume that real-time operation would produce.

Then decide whether real-time alerting is warranted, with evidence rather than an assumption.

Naming the primary control

The discipline that stops a supplement becoming permanent.

For every safety detection, name the control it stands in for: the barrier, the separation, the interlock, the redesign.

Record the detection as interim, with a date for the physical work.

On the risk register with that date, not as a closed item.

Review at the date; if the work has not happened, record why and set a new one.

Report the count of interim measures past their date, which should be small and rarely is.