Property security is a latency problem. The other guides treat it as a checklist.
Every other page on this keyword itemizes physical countermeasures and stops there: deadbolts, fencing, lighting, cameras, landscaping, guards. None of them name the variable that actually decides whether a property loses things or keeps them. That variable is the number of seconds, minutes, hours, or days between something happening on a camera and a human reading about it. This guide measures the gap, names where the seconds leak, and shows the exact point in the pipeline where a 72-hour gap collapses to a 36-second log line.
The checklist everyone passes and still gets hit
The SERP for “property security” is unusually consistent. Every top-ten result opens with some version of the same physical-countermeasure inventory. Reinforce entry points with deadbolts. Put motion-sensor floods on every exterior elevation. Fence the perimeter. Install access control at the gate. Put cameras at strategic points. Trim the bushes. Write an incident plan. The list is fine as far as it goes. It is just not what the keyword is actually about.
Walk any Class B or C multifamily property built after 2012 and you will find most of the checklist already ticked. The fence is there. The lights are there. There are usually twelve to twenty cameras, some of them PoE, some of them coax, all of them recording to a DVR or NVR in a closet by the leasing office. Access control at the gate. A staff group text. A sign at the entrance. And still, once a week or once a month, something walks off the property: a package, a car wheel, a copper line, a resident's peace of mind.
The checklist is complete. The incidents continue. The variable that explains the gap is not on the checklist.
The variable: detection-to-response latency
Detection-to-response latency is the total elapsed time between the frame a camera captures when something happens and the moment a human being actually reads the alert about it. It is not a theory. It is a clock you can hold against any property-security setup and read a number off.
Every property with CCTV has an answer, whether it ever gets measured or not. The median property's answer is “whenever someone complains and we scrub the footage,” which is hours or days. A single overnight guard walking rounds has an answer of “when I happen to be at that monitor or that patrol point,” which is minutes-to-hours per camera. A smart-camera cloud deployment has an answer bounded by upload latency and dashboard response time, which is usually tens of seconds but sometimes minutes under load.
An edge-inference node running on the DVR multiview has an answer measured in the dwell window itself plus sub-second pipeline cost. On the properties where Cyrano runs, the deliveredlatency_msfield typically logs in the tens of seconds. The number below is from a real evening run.
The clock on the same property, three ways
Same 16-camera Class C property, same mailroom incident, three different property-security setups. The first number is the raw time from frame capture to first human read. The checklist does not distinguish between them.
The only one of these four that appears on a standard property checklist is the second, and it is the one most vulnerable to inattention, shift change, and weather.
Where the seconds leak
A property-security pipeline has six stages between photons at the sensor and text on a staff phone. Each stage has a latency budget. On most properties one stage (human review) consumes the entire budget, which is why the total reads “hours or days.” The cards below name the stage, what causes the delay, and what the pipeline below does to close each one.
Stage 1. Optical capture
Camera sensor and lens. Already installed on every CCTV property. Sub-frame latency. This stage almost never leaks seconds on its own.
Stage 2. Encoding + disk write
DVR composites feeds into the multiview and writes to disk. Tens of milliseconds. This stage only leaks time when the disk is failing, which is a separate problem.
Stage 3. Signal access
The bridge from the recorder to a detection process. Conventional approach pulls ONVIF or RTSP per camera, which stalls on credentials and firmware mismatches. Cyrano taps the HDMI multiview, one cable, 25 tiles at once.
Stage 4. Review + classification
The biggest leak. If this is a human, the latency is whenever-someone-looks (hours to days). If this is an edge inference model, it is tens of milliseconds per frame.
Stage 5. Scope filters
Zone, dwell, and armed-time-window gates. Adds a deliberate dwell delay (the seconds the actor must remain in the zone before the alert is credible) and strips false positives from residents and vendors.
Stage 6. Egress channel
The channel the alert travels on to reach a reader. New apps and portals add login friction and notification delay. A webhook into an existing WhatsApp thread is the shortest possible path: no new client, no new login.
The pipeline with the clock on it
Below is the same pipeline collapsed into a single signal path. The left edge is hardware already installed on any CCTV property. The right edge is a channel staff already read. The hub is the three stages that actually need to be added to measure the clock: signal access, inference, and scope.
capture -> multiview tap -> mask + detect + scope -> delivery
The one event line that settles the argument
The anchor fact of this whole page is that the clock exists as a field. Below is a compressed segment of the internal event stream for one mailroom camera across three evening hours on a production property. Most raw detections are silently dropped by one of the three scope filters. The survivor carries an explicitlatency_msfield. That field is the property-security clock the other guides refuse to put a number on.
Read the second-to-last line. 36,112 milliseconds is 36.1 seconds from frame capture to WhatsApp send. The bulk of that time is the dwell window (the scope filter requires the actor to be in the zone long enough to count), not inference or network cost. The point is not the exact number; it is that a number exists at all and can be plotted against every site in a portfolio.
“Every delivered alert carries a latency_ms field timing the pipeline from frame capture to WhatsApp send. On a property where the baseline was hours or days of scrubbing, the clock now reads in the tens of seconds on every event.”
Cyrano event stream, production multifamily deployment
Tour the latency model, stage by stage
Below is the same pipeline unrolled into a sequence you can watch advance. Each frame corresponds to a stage; the body text names what happens during that stage and what the latency budget looks like. The animation is not a metaphor. It is the pipeline the event above went through to produce a 36-second log line.
How a frame turns into a staff WhatsApp message
Frame captured
The install, step by step, with the clock starting
The reason the clock can be this short is that the install touches only the three missing stages. The cameras, the cabling, the recorder, and the staff WhatsApp thread are not in scope. That is what produces the under-two-minute physical install and the “live in one afternoon, not one quarter” tagline.
Install timeline, measured in minutes
Step 1. HDMI out of the DVR, HDMI into the node
The DVR already has an HDMI multiview output driving the guard monitor. An HDMI splitter tees that signal into the Cyrano node. The guard monitor does not lose its feed. Under 60 seconds.
Step 2. Power and ethernet
The node draws from a standard outlet in the same rack as the DVR. Ethernet goes to the property uplink. No new VLAN, no new firewall rule. Under 60 seconds.
Step 3. layout_id detected and mask cached
On first boot the node classifies the multiview into a layout_id (4x4-std, 5x5-std, and so on) and computes the overlay mask once. Cached and keyed by layout_id. Automatic.
Step 4. Polygon zones drawn in the dashboard
The operator draws polygon zones on each camera tile: mailroom-door, package-shelf, gate-approach, parking-spot-17, conex-box. Dwell threshold and armed window per zone. 15 to 45 minutes for a 16-camera property.
Step 5. First delivered event arrives in WhatsApp
The staff WhatsApp thread starts receiving alerts with tile thumbnails, zone labels, dwell counts, and the latency_ms value. No new app, no new login. From this point the clock on the property is a measurable number.
Before and after the clock exists
Every checklist item on a conventional property-security page is still true on a latency-first property. The difference is whether there is a number attached to the review stage.
Conventional checklist property vs. latency-first property
Every item on the textbook property-security checklist is installed. The cameras record 24/7. Staff has a group text. An incident is reviewed when a resident complains.
- Detection-to-response latency: hours to days
- Incidents surface via complaint, not alert
- Footage review is manual scrub, often unbilled hours
- No number exists for how fast the property reacts
- Cameras function as evidence, not deterrence
How the three common property-security approaches measure up on the clock
The market sells three real approaches to the keyword. None of them report latency as a first-class number. Below is what each one implies about the clock when you look past the brochure.
| Feature | Conventional approaches | Cyrano (latency-first retrofit) |
|---|---|---|
| Stage 3. Signal access | Rip-and-replace with per-camera IP, ONVIF pull, cloud upload. Weeks of integration. | HDMI multiview tap. One cable, 25 tiles. Minutes. |
| Stage 4. Review + classification | Human review (guard or operator). Latency equals whenever-someone-looks. | Edge inference on the device next to the DVR. Per-frame cost in milliseconds. |
| Stage 5. Scope filters | Vendor defaults or unfiltered motion alarms. Alert fatigue or missed incidents. | Polygon zone + dwell threshold + armed time window, per camera. |
| Stage 6. Egress channel | New portal, new app, new login per staff member. | Webhook into the existing staff WhatsApp thread. |
| latency_ms field in the event payload | Not measured. Not logged. Not reportable. | Every delivered event carries an explicit latency_ms value. |
| Year-one cost, 16-camera property | $50,000 to $100,000 hardware + $250/camera/month cloud, or $3,000-$5,000/month guard. | $450 one-time + $200/month software = $2,850 year one. |
| Video leaving the property | Continuous cloud upload for smart-camera systems; tapes for DVR reviews. | Raw video stays on-site. Only the alert payload egresses. |
The full signal path, one row, in order
Four existing components on the left edge, three new components in the middle, two existing components on the right edge. The new components are the only ones the install touches.
capture -> compose -> tap -> mask -> detect -> scope -> deliver
Camera
already installed
DVR
composites tiles
HDMI tap
one cable
Mask
layout_id lookup
Detect
edge inference
Scope
zone + dwell + time
latency_ms logged
What putting a clock on property security changes
The second-order effect of measuring latency is that every conversation about property security stops being qualitative. Regional managers comparing sites stop arguing about which property “feels” safer and start reading median latency by site for the previous thirty days. Underwriters asking for loss-control documentation get a csv. Insurers pricing a renewal have a leading indicator instead of a trailing one. Owners deciding which properties need a second node get a number instead of a hunch.
None of that is possible if the clock does not exist. That is why the one change that matters most for “property security” is the one least-covered on the checklist pages: adding a measurable review stage to the pipeline. Every other item on the checklist is prerequisite hardware. The review stage is where the property turns a recording system into a security system.
The most common objection at this point is “we already have cameras.” That is the argument this page is making. Cameras without a clock are half of a security system. The other half is the three missing stages on one node and thelatency_msfield on every event.
A compact summary
- Property security is defined by 0 variable: detection-to-response latency.
- A property-security pipeline has 0 stages; 0 of them are already installed on any CCTV site.
- The slowest stage is human review; it collapses from hours-or-days to tens of seconds when inference moves to the edge.
- The HDMI multiview tap gives one on-site node access to up to 0 camera tiles without per-camera configuration.
- Every delivered event carries an explicit latency_ms field; a production log line reads latency_ms=36112.
- Alerts exit into the existing staff WhatsApp thread; no new app, no new login.
Want your property's clock read out loud?
Book 20 minutes. We will point the HDMI tap at your DVR multiview on a demo call and show the latency_ms field filling in, live, on your own cameras.
Book a call →Frequently asked questions
What is 'detection-to-response latency' and why does it decide property security outcomes?
Detection-to-response latency is the total elapsed time from the moment a camera captures an actionable frame to the moment a human being actually reads the alert. On a conventional CCTV property it has six stages (optical capture, frame encoding, disk write, frame review, classification, and egress to a staff channel) and on most properties today the review stage is human and asynchronous, which means the total latency is effectively the time until someone files a complaint or checks a feed. That is usually hours or days. Every loss that occurs during the latency window is a loss the cameras recorded but nobody prevented. Cameras without a clock on them are closed-circuit recording systems, not security systems. Latency is what separates the two.
Where does the property-security industry hide its latency numbers?
On vendor pages and checklists they hide it in two ways. First, by listing what cameras 'do' (record, monitor, deter) without specifying when that behavior produces a human-readable alert. Second, by using words like 'monitoring' interchangeably for 'records 24/7' and 'a person actively watching right now.' A continuous recording system has a review latency of whenever-someone-looks. A monitored system has a review latency measured in seconds. On a property checklist these two show up as the same line item. They are not the same.
What does Cyrano actually put in the event log as a latency measurement?
Every delivered event payload includes a latency_ms field that times the pipeline from frame capture on the DVR multiview to the WhatsApp message send. A real line from the internal event stream reads: '21:48:42 event_delivered class=pre_action_zone_entry layout_id=4x4-std latency_ms=36112 channel=whatsapp'. That is 36.1 seconds. The payload also carries the camera name, the zone label that was crossed, the dwell seconds counted, a tile thumbnail, and the layout_id so downstream replay tools can reproduce the exact masked frame the detector saw.
Why is the HDMI multiview tap the point in the pipeline where latency collapses?
Because it removes the two slowest stages. On a conventional property the detection model has to (1) negotiate ONVIF or RTSP per camera and (2) wait for a human to review disk footage. The multiview tap skips both. The DVR already has every camera composited into a tile grid for the guard monitor. A single HDMI cable gives an on-site inference device access to 25 tiles at once with zero camera configuration. The detection model then classifies frames in real time on the edge device, and the scope filters decide which detections become alerts. The sequence 'frame -> mask -> detect -> scope -> deliver' runs in seconds, not hours.
What is the five-filter pipeline that converts hundreds of detections into a handful of alerts?
A 16-camera multifamily property will produce roughly 200 to 300 raw person-detection events per day, mostly residents, vendors, and delivery drivers going about normal life. If all of those became alerts, the staff WhatsApp thread would be noise within an hour. The pipeline is: (1) camera frame from the multiview tap, (2) overlay mask applied by layout_id to hide DVR on-screen graphics, (3) object-aware person/vehicle classification, (4) polygon-zone gate (is the person inside a drawn target zone), (5) dwell-threshold gate (are they there long enough to count), and (6) armed-time-window gate (is the property in an armed hour). Typical output: 3 to 8 delivered alerts per day on a 16-camera site.
If I already have cameras, what does 'add property security' mean in practice?
It means add a real-time detection and scope layer on top of the cameras you own, and deliver the resulting alerts into a channel people already read. For a property with working CCTV that channel is almost always the existing staff WhatsApp thread. No new app, no new login. The physical work is one HDMI cable from the DVR to the Cyrano node, one power cable, one ethernet cable, and a polygon zone drawn on each camera tile through the dashboard. The install is measured in minutes because components one through three of the stack are not being touched.
How much does a latency-first property-security retrofit cost versus a rip-and-replace?
Cyrano is $450 one-time for the device plus $200 per month for the software starting month two. A 16-camera multifamily property is $2,850 in year one and $2,400 per year thereafter. A full smart-camera replacement on the same property typically runs $50,000 to $100,000 up front with $250 per camera per month in cloud subscription fees, and a single on-site guard runs $3,000 to $5,000 per month. The latency gap between those options is structural: the guard watches some cameras some of the time, the smart-camera system pushes frames to the cloud (adding upload latency), and the retrofit node runs inference on the same rack as the DVR.
Why does the event latency example read 36 seconds instead of zero?
Because latency in a real pipeline is not just inference time. The number includes the dwell window the scope filter required before the event was allowed to fire (seconds the actor had to be inside the zone before the alert is considered credible), the mask apply time (microseconds), the classification pass (tens of milliseconds), the polygon-zone decision (milliseconds), the webhook send to WhatsApp (hundreds of milliseconds over a typical property uplink), and the queue until the operator's phone wakes. 36 seconds is what 'real time' actually looks like on a commodity property network. The important number is not the absolute value; it is that a log line exists at all, which is not true of any baseline CCTV deployment.
Does any video have to leave the property for the latency model to work?
No. All detection and classification happens on the Cyrano device in the same rack as the DVR. The only outbound traffic is the alert payload itself: a small tile thumbnail, the zone label, the dwell seconds, a timestamp, the camera name, the layout_id, and the latency_ms value. Raw video stays on the DVR's disk. That keeps bandwidth costs at zero for the detection layer and keeps the architecture compatible with tenant-privacy expectations in multifamily housing.
What categories of property-security incident map cleanly onto the latency-first architecture?
The pattern works well any time the incident has a defined target zone and a pre-action pause while the actor positions. Package theft in mailrooms and lobbies, tailgating at secured entry points, cable and copper theft at transformer pads, HVAC and condenser-cage theft, catalytic converter removal in parking lots, loitering in stairwells and laundry rooms, vehicle entry at closed gates, conex-box breaches on jobsites. In each of those the scope filters (zone + dwell + armed window) convert hundreds of detections into a handful of credible alerts a dispatcher can act on inside the latency window.
Comments (••)
Leave a comment to see what others are saying.Public and anonymous. No signup.