AI video surveillance should be audited, not benchmarked. Four artifacts predict whether it is still running in month three.

Accuracy scores are measured on curated vendor datasets. Your property is not a curated dataset. Two systems with the same 99 percent claim can produce wildly different daily event counts, because the difference in the field is not the model, it is the filter stack, the overlay handling, and the output channel. The thing that predicts whether an installed AI video surveillance system is still being used in month three is not its accuracy number, it is a handful of verifiable artifacts on the device: the overlay mask file, the layout_id cache, the compression ratio over the last 24 hours, and the event payload shape. Those artifacts either exist and look sensible, or they do not. No marketing language in between.

A DVR burns graphics into its HDMI output that are not part of any camera feed: a live clock in the corner, a camera-name strip across each tile, and a channel bug with a recording indicator. If you run person detection on that composite frame without subtracting those glyphs, the model produces phantom bounding boxes around the text and the recording dot. On Cyrano, the overlay mask is computed once per DVR layout at install (for example 4x4-std or 5x5-std) and cached as a file keyed by layout_id. On every frame, inference multiplies the composite by the cached mask in constant time. If the mask file is missing or empty, the system is wasting cycles and producing noise. If it exists and has sensible coordinates for the clock and name strip, you are off to a good start.

The layout_id cache is the set of DVR multiview layouts the engine has observed and built a mask for. On a new install, it will have one entry, typically the default grid layout the guard monitor boots into, for example 4x4-std. After a guard drills into a single camera in fullscreen and back at least once, it will also contain 1x1-std. A healthy AI video surveillance deployment where the operator actually uses the system will show multiple layout_id entries after a week. A deployment where the cache only ever has one entry is not being used by anyone, which is its own failure mode, independent of model accuracy.

The compression ratio is raw camera events (mostly person detections) divided by delivered alerts over a 24-hour window. On a typical 16-camera multifamily property, a day produces 200 to 300 raw person detections from residents, vendors, and passersby. A healthy Cyrano install compresses those to 3 to 8 delivered alerts. That is roughly 50 to 1. If the ratio is below 25 to 1, the channel is going to be muted within two weeks. If it is above 200 to 1, either you drew your zones too tight, your dwell threshold is too aggressive, or the system is dropping real incidents. The target band for an actionable AI video surveillance feed is 40 to 100 raw events per delivered alert.

At minimum: a tile thumbnail cropped from the DVR multiview (not the full multiview), the zone label that was crossed, the dwell in seconds, the camera name, the layout_id active at the time of the event, the end-to-end latency in milliseconds from frame capture to message send, and the event class such as pre_action_zone_entry or loitering_dwell_exceeded. These are not decorative. The thumbnail is what the responder reviews in under a minute. The zone and dwell are what the responder uses to decide whether to talk down, call, or log. The layout_id and latency_ms are what the integrator uses to diagnose regressions. If any of those fields is missing from the payload, the system is not deployment-ready, regardless of what its accuracy number is.

No. The whole point of the artifact-level audit framework is that it applies to the deployment, not the sensor. Cyrano runs on whatever composite HDMI signal the DVR is already driving out to the guard monitor, which covers almost any DVR or NVR shipped in the last decade, including Hikvision, Dahua, Lorex, Swann, Uniview, and most rebrands. No camera firmware changes, no RTSP credentials, no ONVIF negotiation. The audit artifacts are generated regardless of camera brand, because they are properties of the detection pipeline, not the cameras.

Under five minutes once you know where to look. You pull the layout_id cache (it is a small directory of mask files on the device), confirm at least one layout present with a sensible mask. You pull the last 24 hours of event stream logs, count raw person_detected lines, count event_delivered lines, and confirm the ratio is in the 40 to 100 band. You open the last delivered WhatsApp message and confirm the payload has thumbnail, zone label, dwell seconds, camera, layout_id, and latency_ms. If all four pass, the system is healthy. If one fails, the failure mode is usually obvious from the missing artifact.

RFP checklists optimize for spec-sheet language, not for whether the system is still delivering useful output six months after install. Resolution and framerate are hardware properties that you cannot change after purchase, so they are important. But the number of supported object classes is actively harmful: a model that can recognize 300 classes but alerts on all of them will produce hundreds of events per day and get its channel muted. The four audit artifacts in this guide are the minimum floor for a working deployment. Everything else is a preference.