Choosing the Operating Point

Every detector produces a score. The threshold converts it into a decision, and where that threshold sits determines the system's entire behaviour.

What the threshold does

Low threshold: catch more real events, produce more false alarms.

High threshold: fewer false alarms, miss more real events.

There is no setting that does both, and the vendor default was chosen to demonstrate well rather than to suit your costs.

Deciding it deliberately

Cost a missed event. For a safety application this may be severe; for a quality check it is a customer complaint; for a counting application it is a small data error.

Cost a false alarm. Operator time, plus the erosion of attention that makes the next alert less likely to be read.

The ratio between them sets the threshold, and it is a management decision rather than an engineering one.

Write down the reasoning, because someone will adjust it later and should know why it was where it was.

The alert budget

The practical constraint that overrides the theory.

Decide how many alerts an operator can meaningfully handle per shift.

Set the threshold to produce roughly that number, given your measured event rate.

If the resulting recall is unacceptable, the system does not work for this application at this camera placement, and no threshold fixes that.

Naming the budget first prevents the usual outcome, where the threshold is set for recall, the alert volume is unmanageable, and within a month everyone ignores the channel.

Different thresholds for different purposes

One system can serve two operating points.

A low threshold feeding retrospective search, where volume does not matter because nobody is being interrupted.

A high threshold feeding real-time alerts, where precision determines whether anyone reads them.

This is usually the right arrangement and it is rarely offered by default.

Per-zone and per-camera

A single global threshold is wrong for a site with varied conditions.

A camera in hard light needs a different point from one indoors.

A high-consequence zone justifies more false alarms than a low-consequence one.

Tune per camera, record the settings, and treat them as configuration under change control rather than as knobs anyone can turn.

What not to do

Do not tune per demographic group. Adjusting thresholds by perceived group characteristics means classifying people by those characteristics, which is the practice prohibited elsewhere in these notes.

Do not adjust the threshold to make a report look better. It is the fastest way to make the numbers meaningless.

Do not leave it at the default and then report the resulting accuracy as a property of the product.

Do not change it without recording it, because an unrecorded threshold change makes every subsequent measurement incomparable.

Reviewing it

After the first month, with the measured alert volume and the measured miss rate.

Seasonally, because the conditions change.

After any camera or scene change.

With both numbers reported: what was gained and what was given up. A threshold change always trades, and reporting only the improvement is how a system quietly stops detecting anything.

Recording the change

Threshold adjustments are made informally and change the system's behaviour completely.

Treat them as configuration changes under change control.

Record: old value, new value, date, who, why.

Report both consequences: the alert rate change and the recall change. A threshold move always trades, and reporting only the improvement is how a system quietly stops detecting.

Without the record, every measurement across the change is incomparable, and an incident investigation cannot say what the system was doing at the time.

Two operating points, one system

Frequently the right arrangement and rarely offered by default.

A low threshold feeding retrospective search, where volume costs nothing because nobody is interrupted.

A high threshold feeding real-time alerts, where precision determines whether anyone reads them.

Same model, same cameras, two outputs.

Ask whether the product supports it, because many do and it is not presented.

It resolves the usual conflict between wanting to catch everything and needing an alert rate anyone can handle.