AI on edge is two models on one box, because a human at the DVR can change the picture at any moment.

On page one of 'ai on edge' and 'ai at the edge' results, the phrase is used to describe machine-learning inference that runs outside a cloud datacenter on hardware next to the data. The canonical reference implementation is a sensor with an accelerator: a smart camera, a robot, a phone, or a car. The framing is fine, but it takes a critical assumption for granted: that the input to the model is stationary. Same camera, same pose, same crop, forever. What it leaves out is the class of edge AI where the input frame composition itself changes during operation because a human is controlling it. Cyrano is in that class: the HDMI frame coming out of a DVR switches layout whenever the DVR operator touches the front panel.

Because the coordinates of each camera within the frame depend on which multiview the DVR is currently rendering. In a 4x4 grid, camera 07 might be tile row 2 column 3. Toggle to a 5x5 grid and camera 07 has moved. Double-click to full-screen on camera 12 and tiles 01 through 25 all disappear except one. A single monolithic detector cannot be told 'camera 07 lives at these pixels' once and for all. The only correct answer is to ask, on every frame, 'what layout am I looking at' before the detector runs. That first question is answered by a small classifier; the second question (what is in each tile) is answered by the main detector. Two models on one box.

Three files and a directory. The model: /var/lib/cyrano/models/layout-classifier-v3.onnx, a lightweight ONNX graph that takes a downsampled full frame and emits a layout_id. The state: /var/lib/cyrano/state/current_layout, a single-line text file rewritten every frame after hysteresis, read by the tile router. The layout library: /var/lib/cyrano/layouts/<layout_id>/tiles.json, one directory per recognized multiview, each containing the crop rectangles for every tile in that layout plus an overlay mask PNG for DVR chrome (date strip, camera-name banners, PTZ menu). And the fingerprints: /var/lib/cyrano/layouts/fingerprints/*.png, one small PNG per known layout used to bootstrap the classifier when a unit encounters a new DVR firmware.

Hysteresis is the rule that the tile router does not act on a single disagreeing frame from the classifier. Concretely, the current_layout file is only overwritten after 5 consecutive frames agree on the same layout_id. The reason is that a human transition on the DVR is not instantaneous; pressing the front-panel button to go from 4x4 to 5x5 produces a handful of intermediate frames that are neither fully 4x4 nor fully 5x5 (a sliding animation, a reshuffle, a black flash). Without hysteresis, the tile router would thrash for about 150 milliseconds every time the operator switches views, sending a burst of false alerts while a label from the old layout gets mapped to a crop from the new one. Five frames at 15 fps is ~330 ms; in practice the router changes cleanly after the transition completes.

An array of entries, one per on-screen tile. Each entry has tile_index (1..N for that layout), camera_name (the label the DVR overlays on that tile), crop (an {x, y, w, h} rectangle in full-frame pixels at 1920x1080), and mask_ref (the overlay file name for the chrome inside that tile, typically the DVR's own label strip). For example the 4x4-std layout has 16 entries with 480x270 crops, each offset by the expected grid spacing and each with a 22-pixel bottom mask where the DVR prints the camera name. The 5x5-std layout has 25 entries with 384x216 crops. A single-camera full-screen view has one entry with a 1920x1080 crop and a slimmer top mask for the date strip only.

Because the edge unit has no out-of-band signal telling it when the human at the DVR has touched the panel. There is no event bus from the DVR firmware, no GPIO, no serial line. The only input the unit has is the HDMI picture itself. So the only way to notice a layout change is to look for it on every frame. The classifier model is small enough that this costs almost nothing: on the Cyrano reference unit, the classifier runs in ~2.4 ms per frame at 256x144 input resolution, which is under 4 percent of the frame budget at 15 fps. The main detector consumes the other 96 percent.

It falls back to the nearest-match layout and writes an unknown_layout event to the on-device log at /var/lib/cyrano/logs/layout.log with a downsampled fingerprint. The tile router continues using the old known-good layout_id for another 60 seconds, degrading gracefully rather than aborting. On the next OTA window the fingerprint is uploaded to Cyrano; if engineering confirms it is a new DVR firmware, a fresh tiles.json entry is pushed back down and all units on that firmware learn it. This is the only path by which the layout library grows; the unit does not try to invent a new layout from scratch on its own.

In principle yes, and some cloud pipelines do exactly that. The practical problem on an edge unit is that the same human at the DVR is free to choose the picture that the detector sees, including picture-in-picture views, PTZ pop-outs, menu overlays, and the occasional full-screen camera-setup dialog from the DVR firmware itself. A single detector trained on every such permutation has to cover the joint distribution of 'multiview x DVR make x DVR firmware,' which is large, unstable, and expensive to maintain. The two-model split localizes the problem: the classifier has a tiny, cheap label space (about 40 known layouts today), and the detector has a stable input (a known-good crop with its chrome masked out) regardless of what the operator did upstream.

Every outbox line carries the layout_id the unit saw at capture time (for example layout_id: '4x4-std'), so the downstream system can later reason about which DVR view produced each event. It also means that a human operator changing the DVR view mid-incident does not break the incident record; the outbox entries that precede and follow the layout change both have correct camera_name values, because the router honored the classifier's call. If you pull a day of outbox and group by layout_id, you can see exactly which views the DVR spent its time in; this is also how Cyrano detects that a property's operator has started using a layout the fingerprint library does not know yet.

Ask the vendor how their edge AI handles a non-stationary input pipeline. If the demo is a stock IP camera feeding a fixed crop to a fixed detector, that is one narrow shape of edge AI and it will not survive a property where an operator is allowed to change the DVR view. If the answer is 'we run a classifier in front of the detector and route tiles based on the current layout,' ask to see the three artifacts: the classifier model file, the current_layout state file, and the tiles.json directory. On a Cyrano unit those are at /var/lib/cyrano/models/layout-classifier-v3.onnx, /var/lib/cyrano/state/current_layout, and /var/lib/cyrano/layouts/. If a vendor cannot show you those three things, they are running cloud AI with an accelerator, not AI on edge.