An apartment CCTV evidence log is not a folder of mp4 files. It is a structured, append-only table.

No. A clipboard is an incident log written by humans about things humans noticed. A CCTV evidence log is a record written by the camera system about every classified event the cameras captured, whether or not anyone noticed at the time. The clipboard is selective and lossy. The CCTV log is exhaustive within its detection class. The two are complementary, not interchangeable. A clipboard pinned to the night manager's desk does not survive the manager quitting; a CCTV log written to a database does.

Eight load-bearing columns. (1) iso8601_ts, the event timestamp at HDMI ingest, not at human review. (2) camera_id or tile_index, naming where on the property the event occurred. (3) zone, the named area inside that camera (mailroom interior, parking row B, north gate, etc.). (4) event_class, the classified event type (person_in_zone, vehicle_in_zone, package_handled, loitering, after_hours_entry). (5) threat_level, a coarse triage label (low, medium, high) so an operator scanning the log can prioritize. (6) dwell_seconds, how long the subject stayed in the zone. (7) clip_path, a pointer to the preserved short clip stored outside the DVR ring buffer. (8) actor_embedding, a small vector that lets you ask 'show me every prior visit by this same subject' without scrubbing tape. Anything fewer than these columns and the log cannot answer the questions an eviction hearing, an insurance claim, or a police request will ask of it.

Because if every camera writes its own timestamp, every camera's clock drifts independently. On a typical 16-channel DVR with cameras that have been on the network for two years, drift between channel 1 and channel 16 is usually somewhere between 200ms and 4 seconds. That sounds small until you try to reconstruct a person walking from the lobby into the elevator: the lobby camera says they exited at 02:43:09, the elevator camera says they entered at 02:43:07, and now the log shows them inside the elevator before they left the lobby. An opposing attorney calls that an inconsistency. A judge calls it an inconsistency. The fix is to source the timestamp from one place and stamp every per-camera event with that same one. The Cyrano approach reads the multi-tile composite the DVR is already painting over HDMI, so all 25 tiles in one frame share the identical iso8601_ts. There is no clock drift to argue about because the tiles were one picture.

It is small. A single row is on the order of 600 bytes including the embedding, plus a separate clip on the order of 2 to 6 megabytes. A property with 25 cameras producing roughly 200 real classified events per day is generating about 30 megabytes of log per month and about 12 to 30 gigabytes of preserved clips per month. That all sits comfortably outside the DVR ring buffer on a property management cloud share or an evidence drive. The clip stays linked from the row by the clip_path column. When months later a board member asks about a specific incident, the row is what gets queried and the clip is what gets played; the DVR's ring buffer being long since overwritten does not matter because the small archive lives elsewhere.

Three families of questions, in plain English, in under five seconds each. (a) Eviction support: 'show me every entry by the subject in apartment 412 over the last 90 days, with timestamps and entry points.' (b) Insurance: 'show me every loitering event longer than 60 seconds at parking row B between February 1 and April 30, ordered by dwell.' (c) Resident complaint: 'show me everything that happened at the south alley between 2 and 4 AM in the last 30 days, low and high threat both.' If your log cannot answer those three, it is a folder of clips, not a log. The bar is set by what an attorney, an adjuster, or a board member will actually ask for.

Different windows. The log itself, being a few hundred bytes per row, can live indefinitely; there is no operational reason to expire it and good reason to keep it for the same period your insurance carrier or local statute of limitations cares about. Most property management policies land on three to seven years for the structured log. The preserved clips are larger and benefit from a tiered retention: keep all clips for 90 days, keep clips tagged high-threat or linked to a documented incident report indefinitely, and let the rest age out. The DVR's underlying 14 to 30 day ring buffer is unrelated to either window because the log and the preserved clips were exported at event time, not at review time.

Yes, and the chain is easier to keep clean when the log is structured than when it is a folder of files. The chain is a record of every person who touched a row or its clip from creation to courtroom. With an automated event log the first hop is automatic: the row's writer is the system itself, with a service identity, a host name, and an immutable created_at. Subsequent hops (an operator viewed it, a manager exported it, a prosecutor received it) are appended as audit_log rows that reference the original event row by its primary key. A judge asking 'how do you know this footage was not edited' has a five-row answer in writing instead of a verbal hand-wave.

Yes. The Cyrano edge unit plugs into the existing DVR or NVR over HDMI, reads the multiview composite the recorder is already drawing, and writes the structured event log on top. No camera replacement, no rewiring, no cloud upload of raw footage. One unit indexes up to 25 camera feeds. Install on site is roughly two minutes. The original DVR keeps doing its job as the canonical recorder (which is the chain courts have been accepting for decades), and the evidence log sits alongside it as the structured index that turns retroactive review from a four hour scrub into a one second query.