Contact Us
WhatsApp
+65 8012 2467
Email Us
contactus@thopps.com
Learning Series: Foundations of Smart Surveillance
Previous: https://varsity.thopps.com/why-intelligence-cannot-be-hard-coded
How noise turns intelligence into background clutter
Alerts are often treated as the final step of intelligence.
Detect something.
Trigger an alert.
Notify a human.
On paper, this seems straightforward.
In real systems, it rarely is.
Because the hardest part of surveillance is not seeing something —
it’s deciding when something is worth interrupting a human.
The hidden problem most systems discover late
Early systems usually alert quickly.
A detection appears.
An event fires.
An alert is sent.
At first, this feels responsive.
Then something strange happens.
The system becomes accurate —
but unusable.
Not because it misses incidents,
but because it reacts to too many moments.
This is where many deployments stall.
Detection answers “what happened”
Alerts must answer “does this matter”
A detection says:
“There is a person.”
An alert must decide:
“Is this worth attention?”
These are very different questions.
Treating detection output as alert input is one of the most common architectural mistakes.
Intelligence lives in the gap between the two.
Why time is the first filter
Most real-world alerts fail because they trigger too early.
People pass through zones briefly.
Objects appear for a few frames.
Motion flickers.
Systems that alert instantly treat noise as signal.
Mature systems wait.
They require:
- persistence across time
- repeated confirmation
- stable presence
Technically, this is implemented using:
- sliding time windows
- frame counters
- timestamp buffers
Nothing dramatic happens — and that’s the point.
When events need a lifecycle
Another hidden idea is that events are not single moments.
They have a lifecycle.
For example:
- detected
- verified
- active
- resolved
Alerts are only allowed at specific transitions.
This prevents systems from repeatedly shouting about the same situation.
State machines quietly handle this logic in the background.
Why confidence must accumulate
Single-frame confidence fluctuates constantly.
One frame says 0.91.
The next says 0.62.
Then 0.88 again.
Reacting to this noise creates unstable alerts.
Instead, systems accumulate confidence over time.
Only when confidence stabilizes does an alert become eligible.
This transforms jitter into judgment.
The importance of alert suppression
Without suppression, one event can generate dozens of alerts.
To prevent this, systems introduce:
- cooldown periods
- duplicate detection checks
- event identifiers
Technically implemented using:
- Redis keys with TTL
- in-memory event caches
One situation produces one alert — not twenty.
When signals must agree
High-quality alerts rarely rely on one signal.
They wait for alignment.
Examples:
- presence + duration
- movement + direction
- repetition + history
Each signal alone is weak.
Together, they confirm intent.
This is how systems reduce false positives without becoming blind.
Why explainability protects trust
When an alert appears, operators must understand:
- what triggered it
- how long it persisted
- which conditions were met
An alert without explanation feels random.
An alert with reasoning feels reliable.
Trust is built not by urgency —
but by clarity.
Final Reflection
Alerts are not reactions.
They are conclusions formed after validation, correlation, and restraint.
A system becomes intelligent not when it alerts quickly —
but when it alerts only when it should.
After all these layers — detection, time, behaviour, reasoning, and alerts — one final question remains:
What does intelligence look like when everything works together?
In the final article, we’ll connect every piece into a complete system view.
Next in series: From Detection to Decision
