What a camera can and cannot establish
A camera records observable facts: where a person stood, how long they stayed, which zone they crossed, and whether an item they were holding stopped being visible. It cannot establish intent, ownership or wrongdoing. AI-assisted detection inherits the same limit, and a system that pretends otherwise will eventually be wrong about a person rather than a pixel.
The useful output is therefore not a verdict. It is a short, timestamped Suspicious Behaviour event with the clip attached, routed to someone who is authorised to judge it. Events in this category are raised as Manual Review Required by design, not as a fallback when confidence is low.
Behaviours worth instrumenting
Start narrow. The patterns that hold up in production are the ones with a clear geometric or temporal definition:
- Dwell in a low-traffic zone beyond a configured threshold
- Movement against the expected direction of a workflow
- Repeated approach to the same rack or aisle within a short window
- Presence in a restricted area outside scheduled activity
- A handled item that stops being visible before an expected checkpoint
Each of these can be described to a supervisor in one sentence. A rule that cannot be explained that briefly will not survive contact with a shift team. The retail equivalent of the last pattern is covered separately in Retail Loss Prevention Using Existing Cameras.
Context is what removes the noise
The same movement is routine in one place and notable in another. Four minutes beside outbound pallets is normal during a pick wave and unusual at 03:00 on a closed dock. Detection quality comes mostly from context, not from the model:
- Zones: restricted, high-value, staging, customer-facing
- Schedule: shift windows, delivery slots, planned maintenance
- Role expectation: which teams are expected in which area
- Baseline traffic: what normal density looks like in that zone at that hour
Without this layer, a security model produces a flood of technically correct and operationally useless alerts.
The review workflow
A workable flow has four steps and no shortcuts:
- Detection raises a Suspicious Behaviour event with a clip, zone reference and timestamp.
- The event enters a review queue marked Manual Review Required.
- A reviewer classifies it as explained, unclear or requiring escalation.
- The classification is stored with the event so the rule can be measured later.
Step four is the one teams skip, and it is the one that makes the system improve. Reviewer decisions are the only ground truth available for tuning thresholds. The state model behind this queue is the same one used for operational exceptions, described in Operational Event Management Explained.
Keeping the queue credible
A review queue loses authority the moment it is too long to work through. Practical controls:
- Cap events per camera per shift and tune thresholds until the cap is respected
- Suppress repeat detections of the same person in the same zone within a cooldown window
- Retire any rule whose events are classified as explained more than nine times out of ten
Measure review outcomes rather than detection counts: events per shift, median time to first review, share closed as explained, and share escalated to a documented incident.
Rollout note
Begin with two or three cameras covering genuinely sensitive zones, run for a fortnight with review discipline in place, and only widen coverage once the queue is stable. If the same cameras also cover charging bays or packaging areas, AI Fire & Smoke Detection for Warehouses explains how safety events run alongside these without competing for the same review queue. Wording matters as much as tuning: an event that says Suspicious Behaviour invites a look, while one that claims theft invites a dispute the footage cannot settle.
