Surveillance AI is not a detection problem. It is a suppression problem.

A closed-loop pipeline that reads a camera signal, runs an object/behavior detector on every frame, applies a suppression stack (where does it count, for how long, during what hours, how serious), and emits a small, human-readable notification only when all four filters agree. The detector is the part every vendor demos. The suppression stack is the part that decides whether the system is usable on a live property with a human on call. Cyrano's spec is explicit: a detection becomes a notification only if it is inside a drawn zone polygon, persists past a dwell threshold in seconds, falls within that zone's active-hour window, and gets classified into the HIGH threat tier. The detector runs on every frame on every tile, 30 frames per second across 25 tiles in the worst case. The notifications leaving the building are vastly fewer because the suppression drops 99 percent plus of detections by design.

Because the detector is a commodity and the suppression is the deployment. Every serious computer-vision object detector in 2026 can find a person, a vehicle, a package, a crowd cluster, a loiter pattern in 480x270 pixels. The model is open, the weights are downloadable, the class set is standardized. A property manager with 16 cameras already gets thousands of qualifying detections per day from a model like that. What the manager needs is roughly three to five notifications per day, the ones that matter, delivered within seconds of the event. That compression from thousands to five is the suppression stack. Every knob that determines the compression, where zones are drawn, how long dwell must last, what hours are active, which threat tier escalates, lives in the config file that ships with each installed unit. The detector is the free part. The per-property config is the hard-won part.

Stage 1 is spatial: the detection must be inside a zone polygon drawn on the tile image during install. A person walking through a public hallway is not inside any zone; a person standing in a dumpster alcove polygon at 2 a.m. is. Stage 2 is temporal: the detection must persist across the zone's dwell threshold, measured in seconds. A delivery driver walking past the alcove for 0.8 seconds does not exceed a 4-second dwell; a person standing there for 12 seconds does. Stage 3 is scheduled: the detection must fall within the zone's active-hours window (example: pool amenity, active-hours 22:00-06:00 on weeknights). A resident in the pool at 2 p.m. is not an event; the same person at 3 a.m. is. Stage 4 is the threat-tier classifier head: LOW, MED, or HIGH. Only HIGH gets delivered. MED is logged locally for the operator to review the next morning. LOW is discarded. A detection has to agree with all four filters to escape the device as a WhatsApp message.

Around 240 kilobytes total. The structured part is roughly 612 bytes of JSON carrying the timestamp, the property identifier, the camera label (the one the operator typed during install: 'mailroom', 'dumpster bay', 'rear alley'), the zone label, the threat class, the dwell duration that triggered it, and a content hash. The bulk of the 240 KB is one JPEG thumbnail cropped to the detected object's bounding box on the offending tile. That thumbnail is the only pixel data that leaves the property. The full composite frame that produced it, 6 megabytes of raw RGB, stays on the Cyrano device and is discarded in memory after inference. The ratio is roughly 6,000,000 bytes in, 240,000 bytes out, or about 4 percent. And that only happens on HIGH events, which in typical deployments are a handful per property per day.

At a well-tuned property, the large majority. Here is a worked example. A 16-camera property runs the detector on 16 tiles at 30 fps, or 28,800 detections-per-second of opportunity. Most of those frames contain a person or a vehicle in some form during business hours. If the detector fires at anything moving, a conservative rate, you get thousands of qualifying detections per day. After stage 1 (zone polygons drawn only on the five or six tiles that have actual restricted areas), the count drops by an order of magnitude because most of the frame does not matter. After stage 2 (dwell thresholds of 3 to 10 seconds on each zone), transient pass-throughs are eliminated, another order of magnitude. After stage 3 (active hours), day-time traffic through after-hours zones is cut. After stage 4 (the HIGH threat tier), only the classifier's top severity bucket makes it through. The result at deployed properties is usually three to ten WhatsApp events per day. The system's job is to throw away the 99 percent plus that does not need a human.

Because the four stages are ordered, each operates on the output of the previous, and the entire pipeline is designed to suppress. A filter implies bidirectional shaping. A rule implies a yes/no decision at one point. A suppression stack is explicit about its purpose: every stage exists to remove detections that do not deserve a human. That framing matters because it inverts how most 'AI surveillance' marketing is written. The SERP is full of pages that brag about how many objects the AI can classify or how fast the model runs. Those are specs of the detector. Suppression is the specification of how few notifications reach the on-call phone per day. If you cannot state the suppression ratio at a deployed property, the AI is not running in production, it is running in a demo loop.

On the device. All four stages execute inside the Cyrano unit sitting in the same room as the DVR. Zone polygon tests are pixel-coordinate comparisons against each detection's bounding box. Dwell tracking is a short per-zone counter held in memory, indexed by object track id. Active-hour tests are a modulo against the on-device clock. The threat-tier head is a small classifier that runs alongside the main detector and costs roughly 0.3 ms per detection. The only step that involves the network is the final WhatsApp delivery, which is an outbound HTTPS POST to the WhatsApp Cloud API. That means the suppression logic keeps working if the property's internet is down: events queue locally and post when the link returns. It also means the only bytes that ever leave the property are the 240 KB envelopes on HIGH events; no raw frames, no detection stream, no dwell tracker state.

Inside the per-property config record on the device, mirrored to a cloud document store for versioning. The record is a JSON document of roughly 6 to 20 kilobytes and any operator can export it from the dashboard. The important fields for suppression are tiles[].zones (the polygon vertices drawn on each tile), zones[].dwell_sec (the temporal hold), zones[].active_hours (the schedule), and the threat-tier thresholds on the classifier head. A property manager can open that file in a text editor, read the exact polygon coordinates for the restricted alcove behind their building, adjust a dwell from 3 seconds to 6 seconds if they are getting false positives on joggers, and push the change back from the dashboard. The inference loop picks up the new config on the next tick; no device restart.

The suppression stack is identical; only the count of tiles changes. The 25-camera case means the detector evaluates a 5x5 grid at 30 fps, each tile 384x216 pixels, same inference pipeline. The config file gains nine more tile entries. Each tile has its own zone polygons, dwell thresholds, and active-hour schedules. Most of those tiles will have zero zones because most camera feeds point at public space. The detector still runs on every tile every frame, but the stage 1 spatial filter will silently drop almost every detection that falls outside any polygon. That is a deliberate architectural choice: the suppression stack is aware of where the system should be strict and where it should be permissive, per tile, per zone. A 25-camera property does not generate 25/16ths as many events as a 16-camera property; it generates roughly the same number, because the zones, not the camera count, set the event rate.

The classifier head reads a small feature vector extracted from the primary detector's output: object class, bounding-box size relative to the tile, motion vector, dwell elapsed, zone sensitivity weight, and time-of-day relative to the zone's active hours. It produces a three-bucket softmax: LOW, MED, HIGH. LOW is the normal case: a person walked through a zone but the combination of shallow dwell, low zone weight, and mid-day timing does not escalate. MED is the review case: the event is worth keeping locally for morning review but not worth waking the on-call. HIGH is the on-call case: deep dwell, high-sensitivity zone, during active hours, with an object class the operator flagged as serious (for example, person-in-dumpster-alcove at 3 a.m. with dwell over 30 seconds). The tier mapping is tunable per property through the config, because what counts as HIGH at a Class A high-rise is different from a Class C garden-style community; the tuning sits alongside the zones.

Alert fatigue followed by a disabled system. The common pattern: a building installs AI video analytics that fire on every human detection, every vehicle, every motion event. The first week the on-call phone buzzes every few minutes. The second week the on-call mutes the thread. By the third week the alerts are no longer read and the system is operating as a very expensive motion sensor. The detector is doing its job correctly; it is finding everything. The suppression stack, missing, is why the deployment fails. Any AI surveillance product you evaluate should answer one question directly: what is the expected number of notifications per property per day, and what are the four (or however many) filter stages that produce that number? If the answer is 'depends on the model', the answer is that there is no suppression stack.

At a 16-camera Class C multifamily property in Fort Worth, a first-month Cyrano deployment fired 20 notifications over 30 days and caught a break-in attempt among them. Working backward: the detector evaluated roughly 28,800 tiles per second times 16 hours of active day times 30 days, on the order of 40 billion tile-frames. It dropped essentially all of them. Twenty notifications reached the on-call thread. Of those twenty, all were worth a read; at least one was a live incident the property would not otherwise have caught. The compression ratio is the product. If every tile-frame that contained something moving had fired a notification, the thread would have been unusable by end of day one. The suppression stack is not a quality-of-life feature; it is what makes the system work at all.

Yes, and the knob is the dwell threshold plus the zone polygon shape. A dwell threshold that is too long will suppress a fast smash-and-grab. A zone polygon drawn too small will let the attacker walk the edges. The knob for tightening either is in the per-property config. A property that had a near-miss on a dumpster break-in might tighten dumpster-alcove dwell from 4 seconds to 2 seconds and extend the polygon two meters further out from the bins. That change pushes more MED events to HIGH for that zone, which is the correct outcome. The design does not eliminate false negatives by raising all thresholds; it gives the operator a per-zone knob because the right strictness varies. What a suppression stack does eliminate is the category of fails where the property stops reading alerts because there are too many; that fail is the worse one, because it makes the detector useless regardless of its recall.