AI powered surveillance systems are governed by a config file, not a model.

Because at portfolio scale the model is constant and the config is the only thing that varies. Every Cyrano unit across every property ships with the same binary inference runtime, the same class set, the same threat classifier, and the same 612-byte event envelope schema. If you took a unit from property A and swapped it with a unit from property B, the hardware and the software are identical; the unit would immediately misbehave because the overlay mask would be aimed at the wrong clock position, the tile-to-camera map would label the lobby as the parking lot, and WhatsApp deliveries would go to the wrong on-call thread. The divergence lives in the config record, not in the model. That makes the config the operational spec of the system at the property level. Top-ranking articles on AI surveillance talk about the model because it is the photogenic part. The config is the part that actually determines what each deployed system does.

Field one, dvr_profile: the DVR make, model, and firmware stamp observed from the HDMI signal at install (used to pick the right overlay mask template and tile geometry defaults). Field two, layout_id: the compositing mode the DVR drives on its HDMI output, for example 5x5-std or 4x4-std, which determines the tile coordinates for output slicing. Field three, overlay_mask: a list of pixel rectangles within the 1920x1080 frame that get zeroed before inference because they hold non-scene glyphs (the digital clock, the per-tile channel name strip, the channel bug, any static watermark). Field four, tiles: a list of 16 to 25 entries, one per tile in the composite, carrying the tile index, the camera label in English (lobby, mailroom, dumpster bay), the zone polygons drawn on that tile, the dwell thresholds per zone, and the active-hour schedule per zone. Field five, delivery: the WhatsApp thread id that HIGH events land in, plus an optional escalation thread id for after-hours and an optional dashboard group id. That is the whole record. Nothing about the model lives in it.

About four minutes per property on an operator tablet. One minute: plug in the HDMI passthrough and let the unit sample the DVR signal; it reads the DVR make/model from the EDID handshake and writes dvr_profile and layout_id automatically. One minute: the operator confirms which tile is which camera by tapping each tile and picking a label from a dropdown, or accepting the DVR's native channel names if those are human-readable. One minute: the operator draws zone polygons on the tiles that need zones (not every tile needs one; a public hallway can be left permissive) and picks a dwell preset per zone. One minute: confirm the WhatsApp thread link and fire a test event to validate the delivery route. When we profile install recordings, the median total is 3 minutes 47 seconds. The model loads, warms up, and starts running during this time; the config is the only thing the operator actively writes.

It renders the union of the delivered event stream from every config record in the portfolio, indexed by property label, camera label, zone label, and event class. The dashboard does not do inference and does not store raw frames; those live on the devices and leave the property only as the 240 KB per-event payload. What the portfolio view adds is two derived products that do not exist on a single unit. One, cross-property incident trend detection: if the same event class fires at five properties in the same week, a portfolio-level report surfaces it even though no single device saw the pattern. Two, a unified review index where a property manager investigating an incident at property 4, camera 7 can search by label across the whole portfolio without juggling eight different DVR web UIs. Neither of those exists until you have a portfolio of config files whose tile labels and zone ids are consistent enough to be aggregated.

Different DVR brands render the composite frame 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. Everything else downstream in the pipeline (inference model, zone rules, delivery) is indifferent to DVR brand. The config absorbs the difference entirely through dvr_profile (which picks the right overlay_mask template defaults) and the overlay_mask field (which stores the actual rectangles). A portfolio with five properties on Dahua, three on Hikvision, and two on Lorex runs ten units with the same 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 configuration dimension; it becomes a value inside one field.

On-device as a local JSON record that the inference loop reads on startup, and mirrored to the cloud control plane as a versioned document. Every edit (operator re-draws a polygon from the dashboard, changes a dwell threshold, adds a zone) writes a new version with a timestamp, author, and diff. The inference loop picks up the new version on the next tick; there is no device restart. The versioning matters operationally because calibration is not a one-shot event. Properties change: a pool opens earlier for summer, a construction area gets fenced off, a mailroom moves, a new camera gets added to the DVR. The config is the running log of those changes. The cloud mirror exists for three reasons: it survives a device swap (plug a new unit into the same DVR, pull the last config from the cloud, you are back online), it makes portfolio-level audits possible, and it lets a regional manager tune zones across several properties without visiting each site.

No to both. The config holds only structured state: coordinate rectangles, labels, polygon vertex lists, numeric thresholds, timestamps, and route identifiers. No video, no images, no embeddings. No per-property model weights are trained or stored, because every unit runs the same public detector checkpoint. There is no face database, no vehicle database, no license plate index attached to the config. That is a deliberate architectural choice. The consequence is that a config record can be exported, reviewed, and audited as a plain text document, and nothing in it is private personal data that a property manager would have to treat as a protected asset. The config can be emailed to a compliance lawyer. The model weights are the same open checkpoint across every deployment.

Between 6 and 20 kilobytes, JSON-serialized and unminified. A minimal install with 16 tiles, two zone polygons drawn, and one delivery route comes in around 6 KB. A heavier install with 25 tiles, three or four zone polygons per tile, custom dwell thresholds per zone, active-hour schedules, and two escalation threads comes in around 20 KB. For reference, the composite video frame the device sees every 33 milliseconds is 6 megabytes of raw RGB. The entire operational spec of the system fits inside a single video frame by a factor of roughly 300 to 1000. That compactness is why the config can be versioned aggressively in the cloud, why a device can boot from cold with a fresh config in seconds, and why a portfolio of 20 properties occupies a fraction of a megabyte of state total.

The operator opens the dashboard for that property, clicks re-scan, the unit re-samples the HDMI composite, and the layout_id may or may not change (a new camera on an existing DVR that was running 4x3 with one empty tile is still 4x4; a DVR that bumps from 2x2 to 3x3 is a layout change). If the layout changes, the tile coordinates for output slicing re-generate and the operator confirms the new tile-to-camera mapping via dropdown. If the layout stays the same, only one line in the tiles array changes: the previously empty tile gets a camera label and optional zones. The detector does not need retraining; the new camera is just one more tile in the composite it was already processing. Total operator time to absorb a new camera is under 60 seconds.

Yes to both. Any operator can export their property's config as a JSON file from the dashboard and open it in a text editor. That is the right behavior and a credible shape for any AI surveillance system you are evaluating: the document that defines what each deployed unit does should be inspectable by the property that runs it. Vendors who cannot show you the per-property config are either not operating under one (in which case their system is identical-as-deployed across every customer, and every property manager gets the same false-alarm profile) or they are hiding it behind a non-auditable cloud blob. Neither is acceptable at portfolio scale. The right question to ask any AI surveillance vendor during evaluation is: show me the 20-kilobyte document that will be different between my two buildings, and walk me through every field.

Not atomically in a database sense, but sequentially with a guaranteed order. A portfolio-level edit pushes a new version to each device's config record in sequence over the cloud control plane, and each unit picks up the new version on its next inference tick (within one second in typical network conditions). If one device is offline, its update queues; when it reconnects it pulls the latest version. The system records which version of the portfolio template each property is running, so a regional manager can see that nine of ten properties are on template v14 and one is still on v13, then act on the lagger. This is a deliberate design choice: it is more important that a property never goes dark during a config push than that the push be instantaneous everywhere.

The cloud mirror of the per-property config is authoritative. Plug in a new device, scan the property QR code, the device pulls the last known config (dvr_profile, layout_id, overlay_mask, tiles, delivery), validates against the live HDMI signal, and is running events again within roughly 90 seconds. Zones do not have to be re-drawn, labels do not have to be re-typed, WhatsApp threads do not have to be re-linked. The entire per-property state is the JSON record. Hardware is treated as replaceable; the config is the durable asset. Contrast that with per-camera AI deployments where the state of the system is spread across N camera firmwares, a cloud region, and a vendor-specific dashboard, none of which can be exported as a document you own.