AI edge is not a latency claim. It is a continuity claim. Here is the file that proves it.

On page one of 'ai edge' results (NVIDIA, IBM, Cisco, HPE, Red Hat, Dell), the phrase is used to name inference that runs outside a cloud region on hardware close to the data source. The benefits listed are always the same triad: lower latency, lower bandwidth, better privacy. That triad is correct but incomplete. It treats the upstream link as if it were always present. The missing definition is continuity: AI edge is the category where detection and alert queuing continue to work when the upstream is not present, so the system does not degrade into a dashboard that says 'unknown' for four hours.

An append-only NDJSON file at /var/lib/cyrano/outbox/YYYY-MM-DD.jsonl. Every emitted event is one line of JSON containing the device_id, a monotonic local_seq counter, the composite layout_id, the camera name, the detection class, a thumbnail path, and the capture timestamp. When delivery to WhatsApp or SMS fails, the line is not lost; it stays in the file. On reconnect, a drain worker reads forward from the last acknowledged local_seq and re-posts events in strict order. The server collapses duplicates by (device_id, local_seq) so the at-least-once retry is safe.

Because the identity of an event on an edge device has to survive both the network being dead and the clock being wrong. A uuid requires a random source and cannot be ordered. A wall-clock timestamp collides during NTP correction after a boot with no network. A per-device monotonic counter kept on local storage gives you: strict ordering for the drain, a stable dedupe key on the server, and a visible gap audit if a counter value never arrives. The cost is one 8-byte write per event to /var/lib/cyrano/meta/local_seq.

What does not break: HDMI capture, layout classification, overlay-mask subtract, the forward pass, the zone filter, the dwell filter, the thumbnail crop, the outbox append, and the on-device event log. Inference keeps running at the normal frame rate, and every triggered event is persisted with a local_seq. What does break: live delivery to WhatsApp and SMS, dashboard push updates, and cloud backups of thumbnails. Those are deferred, not dropped. When the link returns, the drain worker walks the outbox forward and the dashboard backfills. A six-hour uplink blackout at a typical 16-camera property leaves low tens to low hundreds of queued events in the file and drains in seconds on reconnect.

Yes. DNS failure, TLS handshake failure, and WhatsApp 5xx are all folded into the same 'delivery failed' branch of the send loop, so the event sits in the outbox until the next retry tick. The retry tick uses jittered exponential backoff between 5 seconds and 5 minutes, so a rebooting ISP router does not amplify into a send storm the moment it comes back. The backoff state itself lives on disk, so a reboot mid-outage does not reset the schedule.

A cloud-AI system defines detection as a pipeline that begins when the frame arrives in the cloud. During a WAN outage that pipeline is not partially degraded, it is absent. No frames arrive, so no inference runs. Incidents that occur during the outage are only recoverable by forensic review of whatever the on-prem recorder was independently storing. With edge AI the inference is local, so the same outage leaves you with a queue of real alerts waiting to drain, not a silence.

It is a single line of JSON, roughly 400 to 800 bytes depending on metadata, ending with a newline. Keys: device_id (the hardware serial), local_seq (monotonic u64), captured_at (ISO-8601 in UTC), layout_id (for example 4x4-std), camera_name (human name from the DVR name strip), event_class (pre_action_zone_entry, loitering_dwell_exceeded, tailgate_detected, package_dwell_exceeded, and so on), zone_id, dwell_seconds, thumb_path (for example /var/lib/cyrano/thumbs/<sha256>.jpg), and model_tag (for example person-v7@a1f2c9). That line is the envelope the unit commits to before it even attempts to call WhatsApp.

Because an edge AI unit runs a specific model build at a specific moment and that version has to be legible after the fact. If an operator pulls the March outbox to investigate a disputed incident, the model_tag tells them exactly which weights generated the detection. When the model is updated on a later OTA push, old events still reference the old tag; the new tag only applies to events generated after the swap. Compliance, insurance review, and internal postmortem all require that trail, and it cannot be reconstructed on the cloud side because the cloud only ever sees the drained event, not the device state that produced it.

No, and deliberately. It is an append-only flat file with one event per line, rotated daily. The choice avoids a live process holding a database file that would need to survive power loss, corruption, and reboot. A flat NDJSON file is resilient to abrupt power cuts in a way that a writing database is not; the worst case is a truncated final line, which the drain worker detects and discards. The schema is human-readable, so a field technician can open the file on a USB keyboard, tail the last 50 lines, and see exactly what the unit emitted during the window in question.

It shifts the evaluation from 'how fast is inference' to 'what is the operational posture when the link goes down.' Ask the vendor where events are buffered during a WAN outage, how long the buffer survives, what the dedupe key is on the server, and whether the retry backoff state survives a reboot. A product that cannot answer those four questions with a concrete file or table is not really edge AI; it is cloud AI with a local accelerator. Cyrano answers all four with /var/lib/cyrano/outbox/*.jsonl, 'until disk fills,' '(device_id, local_seq),' and 'yes, the backoff state is persisted to /var/lib/cyrano/meta/retry_state.'