The part of an AI surveillance system nobody writes about is the pipeline between the detector and the phone.

The detector is the part everyone shows in a marketing demo: a model fires a person-class bounding box on a camera frame. On a 25-camera property running at even conservative inference rates, the raw detector fires hundreds of times per hour. Almost none of those firings are events a human needs to see. The suppression pipeline is the chain of stages that sit between the raw firing and the operator's phone, and its job is to drop everything that is not actionable. On Cyrano the chain has seven named stages (per-tile overlay mask, class filter, zone-in-polygon check, dwell timer, threat classifier, deduplicator, delivery router). The detector is a commodity; the suppression pipeline is the product, because it is the difference between a system that buzzes an operator ten times a day with real events and a system that buzzes two thousand times and gets muted.

Stage 1, per-tile overlay mask: zero out the DVR clock, the per-tile channel name strip, and the channel bug on every tile, so those pixels cannot fire the detector. Stage 2, class filter: keep only person, vehicle, package; drop animals, foliage, light artifacts. Stage 3, zone-in-polygon: check whether the bounding box center is inside an operator-configured polygon for that tile (trash area, entry, package room, restricted zone). Stage 4, dwell timer: require a minimum persistence in the zone (typically 2 to 8 seconds depending on zone class) before the event is real. Stage 5, threat classifier: a second model that looks at the event context and returns LOW or HIGH, where LOW goes to the dashboard but not to a phone and HIGH wakes a human. Stage 6, deduplicator: suppress if the same zone on the same tile fired in the last N seconds. Stage 7, delivery router: pick the right operator WhatsApp thread for this property and zone class, and push a 240 KB payload to it.

Because the composite multiview frame the DVR renders to HDMI has three always-on features that look like edges and contrast to a detector trained on natural images: a digital clock in the bottom corner, a per-tile camera name strip, and a channel bug. A raw detector will fire occasionally on the clock (because digits change and the model sees motion), on the name strip (because a narrow horizontal bar of high-contrast pixels resembles certain learned features), and on the channel bug (for the same reason). The overlay mask zeros those pixel rectangles before the detector ever sees them. That is stage 1. Stage 3 exists because most of the pixels in a property camera feed (sidewalks, hallways, parking aisles) are places where a person is not interesting. A person walking down a public sidewalk at 2 PM does not need to wake a human. A person in the trash compactor alcove at 3 AM does. The polygon is how the system encodes that difference per property, per tile.

It is a second model that runs only on events that already passed stages 1 through 4. Its inputs are the event context, not raw pixels: the zone class (public, semi-private, restricted, after-hours-only), the time of day (business hours, evening, overnight), the dwell seconds in the zone, the class of the detection (person, vehicle, package), and the event history for that tile in the last 30 minutes (is this the tenth loiter this hour or the first). The output is a score plus a label. HIGH goes to WhatsApp with a phone buzz. LOW goes to the dashboard as a logged event but does not ring. A concrete example: a person detected in the pool area at 11:45 PM with an 18-second dwell is LOW because the pool closes at 10 PM and single-party loiters in that zone have a high false-alarm rate during the summer. The same detection in the trash compactor alcove with the same dwell is HIGH because that zone has no legitimate overnight traffic.

On a typical Class B or C multifamily deployment on a 16 to 25 camera DVR, the raw detector fires at roughly 200 to 500 hits per hour across all tiles during daylight and 20 to 80 per hour overnight. The operator sees roughly 5 to 20 HIGH events per day delivered to WhatsApp. That is a suppression rate in the 99 percent plus range between stages 1 and 7. The rate is not a tunable marketing number; it is the natural consequence of how restrictive the zone polygons, dwell thresholds, and threat rules are set during install calibration. A property that configures twenty restrictive zones will see fewer events than a property that leaves most cameras in permissive default zones.

Because the public writing is produced by three constituencies, and none of them have a reason to describe it. Policy researchers write about capability (Brookings, ScienceDirect, the ACLU) because the policy argument is at the level of what the system could do if turned up to eleven, not what a deployed system actually emits after filtering. Vendor marketing pages (Pelco, Avigilon, Coram, Volt) list capabilities because capabilities sell demos; a section titled Stage 5 Threat Classifier in a buyer's guide is not a lead magnet. Encyclopedia pages (Wikipedia) define the category rather than describing a specific deployed stack. The suppression pipeline is the thing a property manager actually lives with on day 30, but nobody has a commercial or editorial reason to publish it. That is the gap this page fills.

Per property, and per tile within a property. During install calibration the operator draws polygons on each tile (this is the restricted zone, this is the public zone, this is a no-zone area) and sets per-zone parameters: dwell seconds, active hours, threat weight. A dormant outdoor amenity zone that only matters after 10 PM gets a tight polygon with short dwell and high threat weight during overnight hours, and either a permissive polygon or no polygon during the day. The threat classifier reads those per-zone parameters as inputs. If a property changes operationally (a pool opens earlier for summer, a construction area gets fenced off), the operator re-draws the polygon from a phone and the pipeline picks up the change on the next inference tick.

The overlay mask and the per-tile polygon are both tied to a reference composite frame captured at install. If the DVR layout changes (2x2 to 3x3, a channel renamed, the clock moved), the installer re-runs the calibration from the property dashboard. Re-calibration captures a new reference frame, the operator confirms which tile is which camera in a dropdown per tile, and new pixel rectangles are recorded for the clock, name strip, and channel bug. The detector model is unchanged; only the per-tile coordinates move. The whole re-calibration is under a minute. No firmware flash, no model retrain.

About 240 KB per delivered HIGH event. The payload is three parts: an 18 KB JPEG thumbnail cropped from the tile that fired, a 220 KB H.264 clip of roughly six seconds bracketing the detection on that tile, and a 612 byte JSON metadata object (event id, property id, timestamp, detection class, bounding box, confidence, tile index, zone id, dwell seconds, threat label). That payload lands in the operator WhatsApp thread. Nothing else leaves the device. No continuous upload of the full multiview frame, no face embedding, no license plate string, no gait vector, no upload of any of the 24 other tiles that did not fire. The same payload shape is what has already been published in detail on /t/ai-and-surveillance for readers who want to audit the egress contract.

Four concrete questions the vendor should be able to answer on demand. One, per tile, how many raw detector firings became delivered alerts in the last 24 hours; a vendor with no suppression stack cannot report the first number because it is not recorded separately from the second. Two, show me the per-zone polygon and dwell configuration for my property; a vendor with no zone stage can only point at sensitivity sliders. Three, how does the system distinguish a person walking through a public hallway at 6 PM from a person loitering in a trash alcove at 3 AM; a vendor with no threat classifier will answer with alert rules that treat both as equal. Four, what is the delivery rate to operator phones per camera per day; a vendor without a deduplicator will produce more events than a phone can render without muting. All four answers are either present or they are marketing.