When Not to Use It

The most useful early decision is frequently that this is not the technology for the problem.

When a simpler sensor is better

A door being open. A contact switch, not a camera.

Occupancy of a room. A people counter at the doorway, or a passive infrared sensor.

A machine running or stopped. The machine's own telemetry.

Temperature, presence of liquid, vibration, weight. All have dedicated sensors that are cheaper, more reliable, unaffected by lighting, and raise no privacy question.

Cameras are general-purpose and therefore worse at any specific measurement than a sensor built for it. Reach for a camera when the thing being observed is genuinely visual and varied.

When the process should change instead

Detecting people in a vehicle aisle is a supplement to separating them physically, and deploying the detector instead of the barrier leaves the hazard in place.

Detecting a missing safety guard is worth less than making the guard hard to remove.

Detecting a queue is worth less than changing the thing causing the queue, once you know it exists.

Ask what the intervention would be, and whether that intervention could simply be made permanent.

When the event is too rare

A detector for something that happens twice a year will produce false alarms continuously between occurrences, and by the time the real one occurs nobody is reading the alerts.

Rough test: if the false alarm rate exceeds the true event rate by a large factor, the system's output is noise with occasional signal in it.

Retrospective search is the better tool for rare events: no alerting, no fatigue, and the capability is there when needed.

When you cannot define the event

"Suspicious behaviour" is not a definable class. Neither is "unsafe working" or "unusual activity" in the general case.

If you cannot write down what the system should detect in terms a labeller could apply consistently, the system cannot be built or evaluated.

Vagueness here is the leading indicator of a deployment that will end up inferring things it should not.

When the answer requires identity

And the operational question does not.

Most questions posed as "who" are answerable as "how many", "where", or "was the condition present". Where identity is genuinely necessary, the obligations are substantial and there is a whole section on them.

When the conditions defeat it

Existing wide-angle cameras at the wrong height and angle.

Sites with hours of hard light every day.

Outdoor scenes with weather.

Small objects at long range.

These are fixable with camera work and unfixable with software, which is the most common reason a deployment underperforms and the most common thing left out of the proposal.

The definability test

The check that predicts whether a project can succeed at all.

Write down what the system should detect, in terms a labeller could apply consistently to a frame.

Give the definition to two people and have them label the same footage.

Measure their agreement.

Low agreement means the class is not definable, which means it cannot be trained, evaluated or defended.

Do this before commissioning anything. It is an afternoon and it prevents the most expensive category of failure.

The intervention question

Asked before any detection project, and it frequently ends them usefully.

If the system detects this condition, what will happen?

Who acts, within what time, doing what?

Could that action simply be made permanent — a barrier, a redesign, a process change — so the condition cannot occur?

If the answer is that nobody would act, the detection has no value.

If the answer is that the action could be permanent, do that instead, and the detector becomes unnecessary rather than interim.