An incident is never one camera. Review should be a reconstructed path, not a scrubbed tape.

Because the tool they assume you are using is the DVR's playback client, which is indexed by channel. Every built-in DVR workflow starts with 'pick a channel.' That framing puts the reviewer inside a single camera's timeline before they know which camera the incident actually touched. For most real incidents, a trespasser or a package thief or a vehicle break-in visibly appears on four to eight different tiles in sequence. The first tile you pick is almost never the one with the most useful angle. Reconstruction fixes this by putting a path across tiles in front of the reviewer before they pick anything.

It means the review dashboard returns every event row tagged to a specific subject, in timestamp order, across every tile that subject appeared on. For a mailroom theft that starts at the north gate at 02:41:07 and ends in the south alley at 02:48:22, you get a chronological table: 02:41:07 North Gate, 02:41:44 Parking Row B, 02:42:30 Lobby W, 02:43:10 Elevator A, 02:44:55 Mailroom Interior, 02:46:12 Mailroom Interior, 02:47:30 South Stairwell, 02:48:22 South Alley. Eight rows. Eight thumbnails. One scroll. That is the incident. Playback on any single camera misses 7 of those 8 moments.

Because Cyrano classifies the HDMI composite, not the cameras. The DVR paints all 25 tiles into one frame, Cyrano grabs that frame once every 33 milliseconds at 30 frames per second, and every per-tile event written out of that frame carries the identical iso8601_ts. Two tiles cannot have clock drift between them because they were one picture. Cross-tile sort becomes a literal ORDER BY ts. Traditional IP camera rigs depend on NTP or PTP to keep 25 separate clocks aligned, and even small drift breaks ordering on fast events where someone crosses a doorway in under a second. The composite-frame approach sidesteps the problem.

Two signals. The first is temporal continuity: a person who disappears off tile A at 02:41:44 and appears on tile B at 02:41:46, and tile A and tile B are physically adjacent on the property map, is almost certainly the same person. The second is an embedding match at index time: the per-tile classifier crops the subject, computes a lightweight re-identification embedding, and writes that embedding into the event row. Cross-tile reconstruction is then cosine-similarity over the embedding plus the temporal and adjacency checks. Not perfect. Good enough to triage every real incident without manual tab-switching.

Not for incident reconstruction. DVR smart search is scoped to a single channel and returns motion segments, sometimes tagged with a weak object class. It cannot show you a subject's path across channels because its index is per-channel and its clock ordering across channels is not guaranteed. To reconstruct a path across eight cameras on a Hikvision or Dahua NVR, you run the smart search eight times, manually compare motion segments for plausible handoffs, and stitch the timeline together in a spreadsheet. The reconstruction dashboard collapses all of that into one query.

A PDF with one row per tile, ordered by timestamp, each row carrying the iso8601 timestamp, the tile's human-readable label (OCR'd from the DVR's on-screen camera name strip at install time), the event class, a 480 by 270 thumbnail, and a link to the underlying recorder clip for full context. The DVR itself still holds every frame under whatever retention policy was in place, so the packet works as a table of contents over the raw footage. A typical mailroom-theft packet is 8 to 12 rows across 2 to 3 minutes of real incident time. Detectives read it in under a minute.

Either. The event index is persistent. Once the composite-frame pipeline writes a row, it lives in the events table for as long as the retention policy allows. Most properties set that to 90 days by default. So when a resident reports a package missing from the mailroom three days ago, the dashboard runs the reconstruction query against historical events without replaying any video. The raw DVR recording is also still there as a fallback for the rare window that the classifier missed.

Today: person_in_zone, loiter, vehicle_dwell, vehicle_entry, vehicle_exit, tamper, and package_tamper. The vehicle classes mean that a subject's path can include the parking lot camera tiles even if they were in a car the whole way in, then became a pedestrian at the garage. Coverage keeps expanding. For the common incidents (theft, trespass, vehicle break-in, vandalism), the classifier surface is already wide enough to produce a usable reconstruction. Events outside the classifier surface still show up as raw footage on the DVR, just not as index rows.

For a typical single-subject incident on a 25-camera property: about 4 to 7 minutes from opening the dashboard to having a zipped evidence packet. Breakdown: 20 seconds to set the time window, 15 seconds to confirm the subject across the first two thumbnails, 2 to 3 minutes to scan the full path and verify no false handoffs, 1 to 2 minutes to click export. Compare that to the traditional workflow on the same incident, which is typically 90 minutes to 3 hours of scrubbing across channels on the DVR, plus another hour to stitch the clips into a coherent story.

That the tile labels on the review dashboard match the names painted on the monitor. That is the anchor of the whole system. If the DVR's on-screen label reads 'Mailroom Interior' and the review filter chip also reads 'Mailroom Interior', the rest of the pipeline is grounded in names the property manager already uses. If the filter chips read 'CH1, CH2, CH3', the install step that OCRs the cam_name_strip was skipped, and the incident packet will be painful to read in front of a detective. Check the chips first. Then run a test reconstruction on any event from the last 24 hours to confirm the path orders the way you expect.