Natural language search of DVR footage works against a description index, not the video. Stock DVRs do not write one.

Almost never on the recorder itself. Stock DVR firmware (Hikvision, Dahua, Lorex, Amcrest, Reolink, Uniview, Swann, Q-See, Night Owl, ANNKE, EZVIZ, Bosch, Honeywell, Panasonic) ships a Search panel that takes a date range, a channel number, and a motion-region mask. There is no English-language text input because there is nothing for English text to match against. The recorder stored H.264 frames keyed by (channel, timestamp), not sentences. To make English search work, a separate layer has to write a one-line description per event into a parallel index. The recorder then keeps doing what it does (storing pixels), and the index does what the recorder cannot (storing meaning).

A model writes it once, at capture time, when an event survives the cascade. On a Cyrano unit the chain is: the HDMI tile is grabbed off the recorder, an on-device detector flags a candidate (person, vehicle, unusual dwell), a dwell timer holds the track until it crosses a per-zone threshold, and a 5-frame burst stitched into one image is sent to a vision-language model with a prompt that returns strict JSON. One field of that JSON is one_line_summary, which is the sentence that goes into the search index. Example: 'two adults in dark hooded jackets, one carrying a crowbar-shaped object, approaching the rear gate at 02:14.' That sentence is written exactly once. Every later search hits the sentence as plain text and never re-runs the model.

Because the model only fires on events that survived the cascade, not on every frame. A 25-camera property emits roughly 32.4 million frames a day. Sending all of them to a hosted vision-language model lands near $97,000 per property per day at Sonnet input pricing. The cascade drops more than 99.99% of those frames before they reach the model, so the day's bill is a few hundred descriptions, not 32 million. Once written, those descriptions are text, and a text query against text is effectively free at the millisecond level. The heavy work happened on the day of the event. The search you run six days later is just a string match plus a structured filter.

The query is split into three parts before anything is matched. (1) A time window: 'after midnight last week' becomes an iso8601 range that bounds the rows considered. (2) A structured filter: 'loading dock' is matched against tile.label, the human-readable camera name the DVR already paints onto its multiview strip and that the index keys events by. (3) A text match: 'masked person' becomes a token plus an embedding lookup that scores the one_line_summary column. The intersection is the result set. The video file is never opened during this process. Only when the operator clicks a thumbnail does the timestamp open the corresponding clip on the recorder.

Because channel numbers move and camera names do not. When a tech swaps cameras on a re-cable, or maintenance rearranges the multiview to put the loading dock on a bigger tile, channel 6 stops being the loading dock. Every saved English query that referenced 'loading dock' would silently start returning hits from the wrong camera if the index keyed on channel. The DVR already stamps a human-readable name onto each tile (Loading Dock NE, Mailroom Interior, Lobby W). Reading that name off the composite frame at install time, then keying every event by that name, is what keeps an English query stable across recabling, channel swaps, and layout changes.

Three failure modes. First, queries about things the model never described. If 'license plate' was never asked of the model at event time, no description carries the plate and a search for 'red Camaro plate ABC123' returns nothing. The fix is to add a license plate prompt to the cascade, not to re-run a search differently. Second, queries about things outside any armed zone. The cascade only escalates events inside zones, so an English query about the back fence when there is no armed zone there returns nothing because no event row was ever written. Third, queries against a window before the unit was installed. The index is forward-looking. It cannot retroactively write descriptions for footage from last March if Cyrano went live in May.

Both, joined on the event id. The structured fields (tile.label, event_class, iso8601_ts, property, layout_id, overlay_mask) live in a relational table and are queried with WHERE clauses. The one_line_summary lives next to it and has both a full-text index for keyword matches and an embedding index for semantic matches. A query is parsed into a SQL WHERE for the structured part and a vector + text search for the sentence part. Results are joined back on the event id and sorted by recency. Splitting the index this way is what makes 'after midnight last week' resolve as a hard filter instead of being thrown into the embedding search and confusing it.

Sub-second on a property with 12 to 24 months of indexed events. The structured filter trims the candidate set to a few hundred or low thousands of rows in milliseconds. The text and embedding match runs over those candidates, not the whole index, so the scoring step is cheap. The thumbnail strip renders progressively as the rows resolve. The dominant time is the network hop between the operator's browser and the dashboard, not the search itself. Compare this with the alternative (scrubbing four channels in 4x playback for an hour) and the gap is three orders of magnitude.

Yes. The event table is a normal columnar store on the device with the nine structured fields plus the one_line_summary plus the embedding vector. Read access is exposed over a local SQL surface for integrators who want to script against it, build a custom dashboard, or feed events into a CMMS or insurance reporting flow. Write access is restricted to the Cyrano cascade so the index cannot be polluted by a misconfigured client. Exports are row-by-row JSON, the same shape the dashboard uses internally, so what you see in the search UI and what you pull into a script are exactly the same record.

Two structural differences. First, most app-level AI search is keyed to one camera brand and runs in that brand's cloud, so a property with mixed cameras (a few Hikvision, a few Dahua, a couple of Reolinks) has three separate search experiences and no portfolio-wide query. The DVR-side approach keys on the human-readable tile.label that any recorder paints, which makes the index brand-agnostic. Second, app-level AI search typically runs the model at query time on cached clips, which is why it feels slow and why coverage gaps appear when the cache misses. The description-at-write-time approach pre-pays the model cost on the event, so query time is plain retrieval. Different latency profile, different cost profile, different surface area.

Not for the index itself. On a Cyrano unit the detector, the dwell logic, the description model (when running on a small local VLM), and the index all live on the device at the property. The cloud is only on the egress path: the dashboard fetches the index over an authenticated channel so an operator on their phone can query a property they are not physically at. Footage stays on the recorder under whatever retention policy was already in place. If a frontier model is in the cascade, only the 5-frame burst plus the prompt leaves the property, not raw video. The index is queryable from anywhere; the video stays where it always lived.