Object detection is not monitoring. The two filters after the model are what decide whether you get an alert.

Almost every top-ranked article on this phrase stops at the detection model: the camera sees a frame, a neural network classifies it as 'person' or 'vehicle' or 'package,' and an alert fires. That is object detection, not monitoring. Monitoring is the second stage, the one that decides whether a given detection deserves a human's attention. On a production system like Cyrano that second stage is a zone polygon (is the detection inside a region I care about right now) plus a dwell timer (has it stayed inside the region long enough to mean something), and the event class emitted to the operator depends entirely on those two pieces of state, not on the model itself.

Because a person in a parking lot during business hours is not an event, but the same person at the same pixel coordinate at 2 a.m. behind the loading dock is. The detection model does not care about time or location; it just returns a bounding box and a label. A zone polygon is a per-camera JSON file that names a region (mailroom-door, package-shelf, pool-gate-after-hours) and couples it to an arming schedule and a dwell threshold. A detection only becomes a candidate event when its bounding box centroid falls inside an armed polygon. That filter alone cuts the vast majority of noise detections a model emits over a 24-hour window, and it costs zero extra inference compute because it runs on the coordinates the model already produced.

A dwell timer is a per-track, per-zone counter that measures how long a specific detection has remained inside a specific zone. The zone check is a single-frame geometry test; the dwell timer is a time-series test. It is the dwell timer that distinguishes a person walking through the frame (0.8 seconds in the zone) from a person loitering (90 seconds in the zone). The two tests answer different questions: the zone says 'is this detection in the right place' and the dwell says 'has it been there long enough to matter.' Combine them and you can describe every real surveillance event without retraining the model. On Cyrano the dwell state lives at /var/lib/cyrano/meta/dwell_state so it survives a process restart.

pre_action_zone_entry fires the moment a new track enters an armed zone with a 0-second dwell threshold, used for hard perimeters like pool gates after hours. loitering_dwell_exceeded fires when a track has accumulated 90 seconds inside a loitering zone during its arming schedule. tailgate_detected fires when two distinct tracks cross an ingress zone within 1.2 seconds of each other without an intermediate badge event. package_dwell_exceeded fires when an object classified as 'package' sits in a package zone for 900 seconds without being picked up. All four are defined as (zone, dwell threshold, predicate); the detection model does not change between them.

Consumer and enterprise smart cameras ship with pre-baked zone rules inside the camera firmware, and changing them is either impossible or requires a firmware update. The filter parameters are hidden. A Cyrano unit reads zone polygons and dwell thresholds from plain JSON files on local disk, so an operator who finds that 90 seconds of loitering dwell is producing too many false positives at a specific property can bump the threshold to 120 seconds, reload the config, and the change takes effect on the next detection. No model retrain, no cloud round-trip, no firmware push.

It is a marketing aggregate, not a measured quantity on any specific system. What reduces false alarms is not 'AI'; it is the combination of a decent detector and a tight post-detection filter pipeline. On a Cyrano unit the quantity we can measure is events-per-day per camera. On a 24-hour window at a Class C multifamily property, a raw 'person' detector fires on the order of 800 to 1,500 times per camera. After the zone filter that drops into low tens. After the dwell filter it drops into low single digits. The ratio matters less than the absolute rate, because what an operator cares about is 'can I actually read every alert that arrived today,' and the answer has to be yes.

Yes. Every piece of state the filter pipeline needs (model weights, per-camera zone polygons, dwell thresholds, arming schedules, the dwell counter file) lives on the unit. A full WAN outage does not stop detection or filtering; it only blocks the outbound alert. Events that fire during the outage are written to an append-only NDJSON outbox file and delivered in order when the link returns. That behavior is covered in detail on the AI edge page.

One JSON file per camera at /var/lib/cyrano/zones/<camera_name>.json. Each file is a list of named zones; each zone has a polygon in normalized (0,1) image coordinates, a dwell threshold in seconds, an arming schedule (for example 'after 22:00 local' or 'weekends only'), and an event_class to emit. Because the format is plain JSON and the path is stable, a field technician can open the file on a USB keyboard and see the exact rules the unit is evaluating. Editing a polygon is a text edit, not a support ticket.

Yes, and that is the whole point of plugging into HDMI. The Cyrano unit decodes the DVR's on-screen composite (for example a 4x4 grid) into tile coordinates, runs the detector over the entire 1920x1080 frame once, and then attributes each detection to a camera based on which tile its centroid landed in. The zone polygons for each camera are expressed in the tile's local coordinate frame, so a polygon drawn on mailroom-01 stays on mailroom-01 even if the grid layout changes from 2x2 to 4x4 later; only the tile mapping changes, not the filter rules.

Four questions. Where are the per-camera zone rules stored, and can I read them. How is the dwell threshold set for each event class, and can I change it without a model retrain. What is the unique identifier used to dedupe a single track across consecutive frames. How does the system behave when the upstream link goes down for six hours. A vendor that cannot answer those four with a specific file path, a specific integer, a specific dedupe key, and a specific buffering behavior is shipping object detection with a dashboard on top, not a monitoring system.