Detection is not delivery
A perception system can be entirely correct and entirely useless. It can identify a person loitering by a side door at 2am, record it, log it, and reach nobody — because the token expired, the site's uplink was down, or the alert went to a group chat that three people muted in March.
This is worth stating plainly because the two halves are usually owned by different levels
of care. Detection gets benchmarks, baselines and argument. Delivery gets a function called
send_message and no further thought. In deployment, the second half is where
trust is actually won or lost.
What an alert has to carry
The minimum useful alert answers four questions without the recipient going anywhere:
- What happened — a person present, a dwell threshold exceeded, a zone entered.
- Where — which camera, which zone, in language the recipient uses, not an internal identifier.
- When — with a timestamp that can be trusted, which means the clocks have to be right.
- Proof — a still and a few seconds of video.
That last one is disproportionately important. A text-only alert makes the recipient stop, open something, log in and look, which means in practice that most alerts are never verified at all. An alert carrying its own evidence can be judged in about two seconds from a phone, which is the difference between a system people use and a system people mute. See Evidence-Driven Automation for why evidence belongs at the decision point rather than in a database somebody could consult later.
The honest version of "nothing leaves the site"
Edge systems are often marketed as though nothing ever leaves the premises. The accurate version is more specific and, for anyone doing a privacy assessment, more useful:
- Continuous analysis happens on the node. No stream is sent anywhere to be understood.
- The recorded archive — the hours of footage, the bulk of the personal data — stays on local storage.
- An alert has to travel to reach a human who is not on site. That is a deliberate, bounded egress: a caption, a still, and a short clip, to recipients the operator chose.
Those three sentences are a data-flow description someone can actually assess. "Nothing ever leaves" is not, and it tends to collapse under the first informed question. The practical control is to keep the egress small, enumerable and configurable — and to write it down. Video Surveillance and Privacy Compliance covers where that record belongs.
Delivery failure is not alert failure
These two events look similar in a log and mean completely different things:
- The system did not consider this situation alertable.
- The system raised an alert and could not deliver it.
Collapsing them is a common and costly design mistake. A system that treats a failed send as "no alert" will report a quiet night. A system that keeps them separate can say something far more useful: eleven alerts were raised, nine were delivered, two failed, and here they are. That distinction also makes the health of the delivery channel itself observable — which matters, because the channel is the part most likely to break silently while everything else keeps working.
Channels, and their real trade-offs
- Messaging apps — arrive where people already look, carry images and video well, and need no app installation or training. The trade-off is a dependency on a third-party service and an account, and alerts sharing space with personal conversation.
- Email — universally available, easy to archive, and consistently too slow to be an operational alert. Good for summaries, poor for "someone is at the door now".
- SMS — resilient and reaches phones without data, but carries no evidence, so every alert becomes a trip to go and look.
- A local console — full evidence, no third party, nothing leaving the site at all. The limitation is that it only reaches someone who is there and looking.
- An integration into existing systems — a VMS, an alarm receiving centre, a webhook into whatever a site already runs. The best answer when one exists, because it reaches the people already trained to respond.
Most real deployments need at least two: one that reaches a person immediately, and one that holds the complete record for later.
Live and replay must not look the same
Perception systems are tested against recorded footage constantly — it is the only way to evaluate changes honestly. The hazard is a test run producing messages indistinguishable from live operational alerts. Somebody receives a 3am intrusion alert from a clip recorded last March, and the next real alert is trusted a little less. Whatever the mechanism, live operation and replay have to be separable, and only live operation should be able to dispatch an operational alert.
Where ManasaView fits
ManasaView treats alerting as policy rather than code: a read-only layer over the confirmed event stream, deliberately isolated from the perception pipeline underneath it. Delivery failure is never conflated with alert failure — the two are recorded separately — and dispatch runs off the perception loop, so a slow or failing network cannot stall the system that is watching. Every alert carries a still and a short clip, and only live operation is permitted to dispatch one. See it on your own cameras.
Frequently asked questions
If the system runs on the edge, why does anything leave the site at all?
Because an alert nobody receives is not an alert. Analysis and the recorded archive stay on the node, but reaching a person who is not standing in front of it requires sending something out — at minimum a notification, usually a still or a short clip so the recipient can judge it. That path is small and enumerable, and it should be stated plainly rather than hidden behind a claim that nothing ever leaves.
What is the difference between an alert failing and its delivery failing?
An alert failure means the system did not recognise the situation. A delivery failure means it did recognise it and the message did not arrive — the network was down, a token expired, a service rate-limited. They need different fixes and different records, and a system that conflates them will report itself as healthy while nobody is receiving anything.
Should an alert include a clip or just a notification?
Include evidence. A text alert forces the recipient to stop what they are doing and go and look, which in practice means most alerts are never verified. A still plus a few seconds of video lets someone decide in about two seconds whether to act, and that single change does more for trust than any detection improvement.
What happens to alerts when the internet is down?
On an edge system, detection, recording and evidence capture continue, because none of them depend on the link. Delivery is what stops. The important design questions are whether the undelivered alerts are still recorded locally, whether they are retried when connectivity returns, and whether anyone is told that delivery itself is broken.
Can a replayed recording produce a false live alert?
It can, in systems that do not distinguish live operation from replay. Testing a system against recorded footage is normal and necessary; a test run producing messages that look identical to real alerts is not. The two modes need to be separated so that only genuinely live operation can dispatch an operational alert.
← Back to Knowledge