Multifamily housing is already wired for one AI unit per building. The shape of the DVR composite is the shape of the property.

HUD defines multifamily as a property with at least five residential units, each with a complete kitchen and a full bath. Below that threshold a property is still multi-unit (duplex, triplex, fourplex) but sits on the one-to-four-family lending track and is usually surveilled at the unit door level with consumer devices. At five units and above you cross into the category where a centralized common-area stack exists: a lobby camera, mailroom camera, laundry room camera, pool deck camera, parking lot camera, rear entry camera, elevator cab camera, stairwell camera, dumpster bay camera. Those cameras land on one or two shared recorders (DVR or NVR) in a closet off the leasing office. The five-unit threshold is also the threshold where a shared recorder becomes economical, and it is the point at which a single edge AI unit per building starts to make more sense than per-camera intelligence.

A garden-style multifamily property with 50 to 150 units typically runs 9 to 16 cameras on a single DVR: entries, lobby, elevator cab, mailroom, a few hallways, laundry, parking. A mid-rise or large suburban multifamily (200 to 500 units) runs 16 to 25 cameras on one DVR: add pool deck, gym, package room, rear entry, dumpster bay, bike storage, EV charging. A high-rise runs multiple DVRs, one per tower or per floor group, each carrying 16 to 25 cameras. Twenty-five is meaningful because it is the limit of the standard 5x5 HDMI multiview composite that Dahua, Hikvision, Uniview, and Lorex DVRs drive to their guard monitor output: 1920x1080 divided into a 5x5 grid of 384x216 tiles. Cyrano's 25-tile layout ceiling is shaped to that reality. One edge unit, one DVR, one HDMI cable, one building.

Swap one HDMI cable. The chain today is DVR HDMI out to guard monitor HDMI in. Install is: unplug the HDMI from the monitor, plug the DVR side into the edge unit's HDMI in, plug the edge unit's HDMI out into the monitor. The unit acts as a transparent passthrough, so the guard monitor still shows the same 4x4 or 5x5 multiview the leasing office staff are used to. The DVR is untouched. No LAN configuration, no RTSP login, no camera firmware updates, no new cabling, no change to the DVR's user accounts, recording schedule, or retention policy. Median install time on a profiled deployment is under two minutes. At uninstall, reverse the cable swap and the stack is bit-identical to what it was before.

A single JSON record, 6 to 20 kilobytes, with five fields. dvr_profile captures DVR make, model, firmware, and the EDID handshake observed on the HDMI signal. layout_id is the composite mode the DVR drives, typically 5x5-std, 4x4-std, or 3x3-std. overlay_mask is a list of pixel rectangles zeroed before inference because they hold DVR-drawn chrome (the clock, the channel bug, the per-tile channel name strip). tiles is a 9 to 25 entry list, one per tile in the composite, carrying the tile index, the camera label in English (lobby, mailroom, dumpster_bay), any zone polygons drawn on that tile, and dwell thresholds and active hours per zone. delivery is the WhatsApp thread id for HIGH events plus an optional after-hours escalation thread. That 5-field document is the entire operational spec of the system at the property level. Every Cyrano unit across every property runs the identical inference binary. Only the config diverges.

Because the DVR already converges the cameras. Every multifamily building has resolved the ten to twenty-five cameras on its roof, in its hallways, and over its parking lot into one composite frame by the time the signal reaches the guard monitor. That resolution happens inside the DVR. An AI stack that wires into the LAN and pulls RTSP from each camera individually has to re-solve a problem the building has already solved. The edge unit reads the DVR's finished work. The per-property config is therefore a map of the composite, not a manifest of the cameras, which is why it is small (under 20 KB) and portable (the same record boots a replacement unit in 90 seconds). On a 10-property portfolio, 10 config files, about 150 KB of total operational state, define what every deployed system does.

Nine placements cover the overwhelming majority of multifamily incident surface: front lobby entry, mailroom, package room, laundry, pool deck, parking lot, rear or service entry, dumpster bay, and elevator cab. Each of those lands on one tile of the DVR composite. Each tile gets a camera_label field (lobby, mailroom, etc.) and one or more zones. A zone is a polygon with a dwell threshold and an active-hours schedule. Example: the dumpster bay tile gets a zone with polygon roughly matching the alcove, dwell 6 seconds, active hours 22:00 to 06:00, so someone pausing in that alcove after 10 p.m. for more than six seconds lifts an event. The pool deck tile gets a zone active 23:00 to 06:00 because pool-hours are posted on the gate. The mailroom gets a zone active 24 hours with dwell 8 seconds, tuned to filter residents picking up mail but not someone lingering by the parcel lockers.

On raw DVR playback the manager sees nothing until something happens, then scrubs through hours of timeline trying to find it. On edge AI on the DVR the manager sees nothing until something happens either, because no-event means no alert. When something happens, the manager gets a WhatsApp message in the property's on-call thread with a still frame from the tile that fired, the tile label (dumpster_bay), the zone label (dumpster.alcove), the dwell seconds observed (11 s against a 6 s threshold), and a link into the dashboard for the 20-second clip. The alert is a 240 KB payload. The raw video stays on the DVR on the property's LAN. That is the difference: the manager gets the event, not the stream, so the review loop is measured in seconds and the bandwidth cost is negligible even across a 25-property portfolio.

Different DVR brands render the HDMI composite with different pixel-level chrome: the clock is in a different corner, the per-tile channel strip is a different height, the channel bug is a different glyph. None of those differences matter to the AI model, but all of them would confuse it if they were fed in raw. The overlay_mask field in the per-property config absorbs them entirely. A portfolio with five buildings on Hikvision, three on Dahua, and two on Lorex runs ten units with one identical model binary, ten different overlay_mask arrays, and ten delivery routes. Nothing else in the stack changes. The operator does not see DVR brand as a top-level configuration dimension; it collapses into one field in one JSON record.

It does not, by design, on the ingest path. The DVR is not exposed to the PMS. The edge unit does not read from or write to Yardi, RealPage, or Entrata directly. On the delivery path, events land in WhatsApp threads that the property manager and regional manager already use, and a cloud dashboard groups events by property and zone for weekly operational review. Integrations that do touch PMS (for example, suppressing alerts from residents during known amenity hours) happen at the config layer: active-hours schedules on a zone are set once and left alone, not synced live from the rent roll. This keeps the blast radius of a misconfigured integration bounded. The surveillance stack cannot accidentally leak resident data to the PMS because the two systems do not share state.

The operator opens the property's dashboard, clicks re-scan, and the edge unit re-samples the HDMI composite. If the DVR bumps its layout (for example, 4x4 to 4x5), the layout_id field updates and the tile coordinates for output slicing regenerate; the operator confirms the new tile-to-camera mapping from a dropdown. If the layout is unchanged because the DVR had an empty tile to fill, a single line in the tiles array changes: the previously empty slot gets a camera label and optional zones. The detector never needs retraining because the new camera is just one more tile in the composite it was already processing. Total operator time to absorb a new camera into a running deployment: under 60 seconds.