Detections are cheap; attention is expensive
Every frame a detector processes can produce several detections. Over a busy scene, that adds up fast — thousands of raw observations per minute, most of them entirely unremarkable: a person walking through, a car passing by, nothing anyone needs to know about. If a system surfaced every detection as something to look at, it would overwhelm an operator within minutes and train them to ignore the system entirely.
An event is the answer to that problem: a decision, built from tracked and confirmed observations over time, that something specific and significant happened — significant enough that a human (or a downstream system) should know about it.
The path from raw signal to actionable event
The stages typically look like this:
- Detection — raw, per-frame observations.
- Tracking — detections become a confirmed, continuous object over time.
- Semantic confirmation — the tracked object is verified as the class that matters (a person, not a shadow).
- Policy evaluation — rules and thresholds are checked against the confirmed track: has it dwelled long enough, has it crossed a zone boundary, does it match a condition worth flagging.
- Event — a policy condition was met; something worth recording, and possibly alerting on, happened.
Each stage filters and compresses what came before it. By the time something becomes an event, it has survived several layers of "is this real, and does it matter."
Why policy should live separately from perception
It's tempting to bake alert logic directly into the detection or tracking code — "if confidence > 0.9, send an alert." That couples two things that change for very different reasons and at very different rates: the perception pipeline (which should be stable, measured, and rarely touched) and the policy that decides what's worth alerting on (which changes constantly — a new restricted zone, a different dwell threshold for a different site, a seasonal adjustment).
Keeping policy as a distinct layer, evaluated over the output of a stable perception pipeline, means those two things can change independently. A new alert rule doesn't risk destabilizing detection or tracking; a perception improvement doesn't require rewriting every alert rule.
Evidence: what makes an event trustworthy
An event without evidence is just a claim. A useful event carries what a human needs to verify it quickly: a snapshot, a short video clip around the trigger moment, the relevant track history, and timestamps. The goal is that an operator looking at an alert can confirm or dismiss it in seconds, not have to trust the system's judgment blindly or go dig through raw footage to figure out what actually happened.
Detection isn't delivery
One design point worth being explicit about: correctly recognizing an event and successfully delivering a notification about it are two different concerns, and conflating them causes real problems. If a notification service is briefly unreachable, that's a delivery failure — it shouldn't mean the event itself wasn't detected or logged. Systems that treat these as one thing tend to lose events silently exactly when something goes wrong elsewhere; keeping them separate means the event record stays accurate even when delivery has a bad moment.
Where Vision Lab fits
Vision Lab treats alerting as policy, not code — a read-only layer over the confirmed event stream, deliberately isolated from the perception pipeline underneath it, and delivery failure is explicitly never conflated with alert failure. It's the engineering foundation behind Vision Lab Studio, Vision Box, Cabin Cam, and Spy Catcher.
Frequently asked questions
What's the difference between a detection and an event?
A detection is a raw, per-frame observation: an object was found here, with this confidence. An event is a decision built from many detections over time — a person dwelled past a threshold, a zone was entered — that's meaningful enough to act on or alert about.
Why not alert on every detection directly?
Raw detections are noisy and numerous — a busy scene can produce thousands per minute. Alerting on each one would overwhelm any operator immediately. Events exist specifically to compress a stream of raw observations into the handful that are actually worth a human's attention.
What turns a detection into an event?
Typically a policy layer: rules or thresholds evaluated against tracked, confirmed objects — has this presence dwelled past N seconds, did this object cross a defined zone boundary, did a confirmed person appear in a restricted area. The policy decides significance; detection and tracking supply the underlying facts.
Should event policy be mixed into the detection code?
Keeping them separate is usually the more maintainable design. Detection and tracking answer "what is happening"; policy answers "does it matter, and to whom." Separating the two means alert rules can change — a new dwell threshold, a new restricted zone — without touching the perception pipeline itself.
What is "evidence" in this context?
Evidence is what supports an event once it fires — a snapshot, a short video clip, the confirmed track history, timestamps. Good evidence lets a human verify an alert quickly rather than trusting the system's judgment blindly.
Does delivery failure count as an event failure?
No, and treating them as the same thing is a design mistake. An event can be correctly detected and logged even if, say, a notification service is temporarily down. Keeping detection/logging and delivery as separate concerns means a delivery hiccup doesn't mean the system missed something.
← Back to Knowledge