The OM says 24 cameras. The multiview says 17 live, 4 frozen, 2 black, 1 duplicate. That gap is what this page is about.

The other page is about a 30 day indexed event log that becomes a pro forma line item. This page is about what happens in the first 5 minutes, before any events are counted. The detector's first output is a per-tile rendering-state vector across 5 states: live_video, frozen_frame, black_signal, duplicate_feed, no_signal. That output exists the moment the HDMI tap is powered on, long before the 30 day window that produces the pro forma number. The two are complementary outputs from the same device: one is an asset condition audit for the DD visit, the other is a portfolio comparable for the underwriting model.

A few reasons, all of them common. First, POE power fails silently and the camera stops transmitting but the tile stays on the multiview as a black rectangle with a channel label. Second, a weather event or a physical impact freezes the camera at its last decoded frame, which looks correct in a thumbnail but is actually a still image. Third, the DVR operator copied a working channel over an unused one during a prior troubleshooting session and forgot to change it back, producing duplicate_feed. Fourth, the coax run was cut during a sub-contractor visit and the channel was never disabled on the DVR. None of these are visible from a leasing tour walkthrough. All of them are visible from the HDMI output of the DVR within seconds.

No. The edge device reads the HDMI output the same way a wall monitor does. There is no log-in to the DVR, no access to the RTSP stream, no admin credential change, no port opened on the network. The cable goes inline between the DVR and the monitor that is already in the office closet. If the investor's inspector or consultant can find the closet, they can run the audit. When the DD visit ends, the cable goes back to the recorder and the device goes with the investor, unless the LOI is signed.

black_signal is any tile whose pixels are under a luminance threshold across the full tile area for more than 2 seconds, which matches the case where the camera is not transmitting at all and the DVR renders a default black rectangle. frozen_frame is a tile whose decoded pixels do not change for more than 15 seconds, which matches the case where the camera is transmitting but its encoder or sensor has stalled and the DVR is rendering a still image. The two look similar to a human glancing at a multiview but mean very different things for the asset: black_signal usually means a POE or coax failure, frozen_frame usually means a camera that needs to be rebooted or replaced.

duplicate_feed is two or more tiles on the multiview rendering the same pixels for more than 90 seconds. It happens when the on-site operator remapped a channel during troubleshooting and the override stuck, or when a camera was physically removed and the DVR channel was reassigned to an adjacent camera without updating the channel map. It shows up as two tiles with different labels but pixel-identical output. Investors who discover duplicate_feed during DD know that the seller is advertising more cameras than are physically installed, which affects both the replacement capex estimate and the insurance conversation.

The classifier runs on a sliding window. By second 15 it has classified every tile as either live_video or candidate for one of the four non-live states. By second 90 it has resolved the candidates: frozen_frame requires 15 seconds of no pixel delta, duplicate_feed requires 90 seconds of pixel-identical output against another tile, no_signal requires the DVR's own no-signal overlay to persist. A 2 minute dwell produces the final 5 state vector. On a 16 tile multiview at a Class B property this is about $450 of hardware and under 5 minutes of DD time to answer a question the OM does not answer.

No. A security consultant walkthrough asks questions the tile vector cannot answer, like whether the cameras are aimed correctly, whether the angles miss an obvious blind spot, whether the on-site staff know the DVR password, and whether the documented access control procedure matches reality. What the tile vector does is close the gap between what the seller says is installed and what the DVR is actually rendering right now. The consultant walkthrough and the tile vector are complementary: the consultant tells you what the program looks like, the tile vector tells you what the hardware actually does.

No. The tap reads HDMI output, runs the classifier on its own on-device GPU, and writes the vector to the Cyrano dashboard that the investor holds. It does not write anything back to the DVR. It does not send anything to the seller's cloud VMS if one is configured. The seller's on-site staff do not see the audit happen and do not see the result. The unit draws power from a wall outlet in the closet, the rest of the stack is not touched.

From an actual DD audit on a 24 tile multiview at a Texas Class B property: live_video 17, frozen_frame 4, black_signal 2, duplicate_feed 1, no_signal 0. The seller's OM listed 24 cameras and used that number in the amenity description. 7 of the 24 were not producing live video at the moment of the site visit. The investor used the delta to renegotiate the security-related capex assumption on the DD memo and adjusted the LOI accordingly. The capex delta was larger than the cost of the Cyrano hardware and 18 months of software combined.

Yes. The same audit runs on stabilized assets you already hold. The tile vector tells you, for every property in the portfolio, how many of the cameras you are paying the regional manager to keep operational are actually operating. A portfolio with 6 sites and an average of 22 cameras per site typically has 20 to 30 cameras in a non-live state at any given time across the portfolio. The audit becomes a quarterly operational discipline check alongside the T-12 and the rent roll.

Four things. First, the tile vector goes into the DD memo as a measured number, not a seller claim. Second, the delta between the advertised camera count and the live_video count translates into a capex adjustment on the underwriting model. Third, the frozen_frame and no_signal counts feed the GL insurance conversation, since a working camera count affects carrier modeling. Fourth, the specific tile labels in the non-live states become a punch list for the property management transition plan at close: these are the cameras that need to be rebooted, replaced, or rewired in the first 30 days of the new ownership.

If the seller is already running a cloud VMS, the tap still works, because the tap reads the HDMI output of whatever recorder or NVR is driving the monitor. The cloud VMS dashboard is the seller's own management surface, which the investor usually does not have credentials for. The HDMI tap is what gives the investor a read without asking for those credentials. In practice, most Class B and Class C multifamily assets do not have a cloud VMS, so the question is moot. On the rare Class A asset with a cloud VMS, the tap is still the fastest way to verify the advertised camera count independently of whatever the seller shows on a platform screen.