Three hundred alerts a shift and nobody opens them

A shift that raises 300 alerts and closes 6 of them does not have a discipline problem. It has an aggregation problem: the system is emitting 1 alert per detection instead of 1 incident per event, and no amount of briefing will train a supervisor out of that. The same detector, with the same accuracy, produces a workable queue once detections are collapsed into events, zones are armed only when the hazard exists, and rules are scoped to the areas that have the hazard.

Nothing else on this page matters until the counts exist. Most safety analytics deployments report alerts raised and nothing else, which is the one number that cannot tell you whether the system is working. Raised against opened against closed is the whole diagnosis, and it takes an afternoon to instrument.

Raised, opened, closed: the 3 counts that end the argument

Pull one week of the notification log and group it by rule, by camera and by shift. Then join it to whatever the console records about human action. If the console records no human action, that is the first defect, because without it every conversation about alert quality is 2 people trading impressions.

Insist on the disposition field. It costs a supervisor 2 clicks and it is the only artefact that tells you later which cause was actually dominant on your site. A console that captures it, plus the rollup that reads it, is the sort of small system we build under internal tools and ops.

Five ways a shift gets to 300, in the order worth checking

These are ranked by volume removed per hour of engineering, not by how interesting they are. The last one is where most teams start, which is why the queue is still unworkable 3 months later.

Only the last row is a model problem, and even then the cause is usually physical. A rule firing on people who are wearing their hard hat is its own trace, worked through in tracing a false PPE violation. If the detector cannot see what it is being asked to judge, the decision moves back to placement, settled during the site survey that decides what the model can see, and to whether a learned detector was the right instrument at all rather than a geometric test, argued in deep learning versus rule-based machine vision.

One person, 40 seconds, 480 frames

The arithmetic is the argument. A detector running at 12 frames a second, watching someone stand inside a restricted zone for 40 seconds, produces 480 positive detections. Emit on each one and you have 480 alerts from a single thing that happened. Throttle to 1 a second and you have 40, which is still 40 notifications for 1 person who walked in and walked out. The unit of alerting has to be the incident, and the incident has to be constructed.

1. Detect per frame, and stop there. Per-frame detections are evidence and belong in storage; they are not events and must never reach a person.
2. Associate detections into a track. A track is 1 person across consecutive frames, with an identifier local to that camera. Everything downstream keys off the track.
3. Open a candidate when a track satisfies a rule. Inside the zone polygon, no hard hat associated, forklift within a distance band: the rule tests the track, continuously.
4. Apply a dwell threshold before a candidate becomes an incident. Three seconds of continuous satisfaction removes the transit case, where someone clips a corner of the polygon.
5. Hold a cooldown keyed on track, area and rule. Re-entry inside it extends the open incident, so someone working at the boundary produces 1 record, not 20.
6. Close on exit, and attach a clip with pre-roll and post-roll around the whole span rather than around 1 frame.

Deduplicating across cameras deserves one caution. Collapsing 2 alerts into 1 incident is right; discarding the second camera's clip is not. The angle you throw away is often the only one that shows what happened, and the cost of that decision only becomes visible during an investigation, which is the situation reconstructed in auditing camera coverage after an incident.

Zones armed while the hazard is switched off

A restricted zone around a press is a hazard while the press is energised. At 22:00, with the line down and the cleaning crew in, the polygon is still there and the rule is still running, and every mop produces a violation. This is the cheapest volume on the site to remove and the most commonly left in place, because arming logic is treated as configuration rather than as part of the rule.

• Give every zone an active schedule. Shift patterns rather than clock hours, on a calendar that knows about planned shutdowns.
• Interlock to machine state where a signal exists. If the controller can publish whether the press is energised, the zone should follow it rather than a timetable that drifts.
• Write down the exception path. Maintenance inside a live zone needs a documented way to disarm it, with a named approver and an automatic re-arm, or people stop reporting.
• Show armed state on the console. A disarmed zone that looks armed is worse than no zone, because it manufactures confidence in coverage that does not exist.
• Do not use scheduling to hide a rule you no longer believe in. If it is off more than it is on, retire it and say so.

Which rules deserve a phone, and which deserve a page in the morning

Severity is not a property of the detector, it is a property of what the recipient is expected to do. Sorting rules into 3 response classes is what makes the real-time queue small enough to be credible, and it costs nothing technically.

The digest does more work than it looks. Low-severity rules carry most of the volume and almost none of the urgency, and as a morning page they become a trend read in 90 seconds; what belongs on it is modelled in a week of automated safety reports. Who receives the top class and what they must do is a separate artefact, owned by the escalation table somebody has to own.

The interruption budget, and setting it before the thresholds

Work it from the recipient backwards. Opening an alert, watching a 20-second clip, deciding whether it is real and doing something about it takes 2 to 4 minutes honestly. Fifteen real-time alerts in an 8-hour shift is therefore up to an hour of a supervisor's shift spent on the queue, on top of the job they were already doing. That is the budget. Every threshold, dwell setting and zone schedule is then chosen to fit inside it.

An alerting system whose volume is decided by the detector rather than by the person receiving it will converge on being ignored, and it will do so quietly.

When the budget cannot be met with the rules currently live, the answer is to run fewer of them rather than to raise every confidence threshold until the numbers look tolerable. Thresholds trade a false alert for a missed one, silently, and the missed one is the expensive direction. Reducing scope until the queue is credible, then expanding, is the staging argued in starting with one zone and one hazard, and it applies just as well to a system already deployed as to a new one.

Prove each change before anyone is asked to trust it: run the modified rule silently for a week, count what it would have raised against the week before, and show both numbers to the supervisor who abandoned the queue. Sometimes the honest conclusion is a different instrument, since a forklift proximity rule producing constant alerts and no behaviour change may be the wrong sensor entirely, which is the choice in camera versus wearable tag for forklift proximity. All of it sits inside the wider safety, PPE and site monitoring programme we build for manufacturing and industrial vision.

• video analytics
• alerting
• safety
• operations