Edge AI is not a place; it is a 9-key file on the boxthat a tenant's attorney can read.

Because the compute-location framing is unverifiable from outside the vendor. A property owner who asks 'where does the inference happen' gets a marketing answer. A property owner who asks 'what is allowed to leave the building' can be handed a path, /etc/cyrano/egress.schema.json, open it with any text editor, and read the 9 keys that are permitted. The schema is the contract. The compute location is an implementation detail that exists because of the schema, not the other way round. Reframing edge AI as an egress-contract category is the move that makes it auditable.

device_id (the cy-<serial> of the unit), local_seq (the monotonic sequence the outbox uses for ordering), occurred_at_unix (the local unix timestamp), camera_id_hash (an HMAC of the property-scoped camera label, never the human label), event_class (one of a fixed enum of about 14 classes, for example loitering, tailgating, package_dwell, trespass_zone_entry), threat_tier (LOW or HIGH), bbox_norm (four floats, x y w h, each in 0.0 to 1.0 of the frame), confidence (one float, 0.0 to 1.0), and dwell_ms (how long the event persisted on the frame). That is the whole envelope. Everything else is a validation failure.

Pixels are not in the schema. No base64-encoded thumbnails, no crop URLs, no face embeddings, no license plate strings, no raw timestamps from the DVR's on-screen display, no operator free-text notes, no WiFi SSID, no local IP address. If a downstream handler tries to write any of those into an event before the outbox, cyrano-egress-validate drops the write and logs a rejection line to /var/log/cyrano/rejected.log. The reason this matters: multifamily leases have tenant-privacy clauses that name pixels and biometrics specifically, and 'our AI runs on the edge' is not a sentence you can hand a lease attorney. A schema path is.

420 bytes, give or take a few bytes per event class. That is one line of NDJSON appended to /var/lib/cyrano/outbox/pending.ndjson. A property that generates 300 events per day, which is roughly the upper bound at a 200-unit Class C multifamily, sends 126 KB of JSON across all cameras across the whole day. For comparison, one 1080p snapshot at JPEG quality 80 is on the order of 180 KB, which is larger than a month of events from an average 50-unit property. The envelope is the point: 'edge AI' here means the building's entire compliance surface is about 100 KB a day of structured text, not pixels.

Before any process on the unit is allowed to append a line to /var/lib/cyrano/outbox/pending.ndjson, it pipes the candidate JSON through cyrano-egress-validate, a small setuid helper that reads /etc/cyrano/egress.schema.json, walks the candidate's keyset, and exits 0 only if the set is a subset of the allowed 9 and every value conforms to its declared type. The outbox writer has no other entry point; the file permissions on pending.ndjson are u=rw,g=,o= and only the validator's group can append. A developer who adds a new field in a future release has to change the schema file to ship it, which is a reviewable diff, which is the audit.

Two things. The candidate JSON is written to /var/log/cyrano/rejected.log with a reject_reason string (for example 'forbidden_key:pixels_b64' or 'type_mismatch:confidence:string'). The outbox is untouched; the network uplink never sees the rejected event. A counter on the property safety dashboard increments a schema_violations metric so a property ops lead can tell at a glance whether a new release is silently producing events the old schema won't accept. No event is partially sent. No 'fallback to cloud' path exists.

They can, but only on the property. The hash is an HMAC with a per-property key stored in /var/lib/cyrano/secrets/property.key that never leaves the unit. On the property, the ops tool cyrano-debug resolve-camera takes a hash and returns the label. Off the property, the hash is opaque. This is deliberate: the person debugging a specific alert is physically at the property and has shell on the box; the person at corporate reading the dashboard sees only the hash and the event class. Privacy boundaries match operational boundaries.

The capture loop sees everything the DVR renders on its multiview monitor. That is intentional; that is how it runs inference. But the capture loop has no outbox write permission. The only code with outbox permission is the event formatter, which takes detector output and emits the 9-key envelope. Raw frames never leave /dev/shm/cyrano/frames, which is tmpfs and wiped on every reboot. A second on-unit process, cyrano-retention, truncates /dev/shm/cyrano/frames on a ring of roughly 45 seconds, so even if someone physically pulls the unit and powers it back on, there is no recent video on it to read.

Yes. A migration bumps /etc/cyrano/egress.schema.json's version string, adds the new key under a migrations block, and ships in a firmware image. cyrano-egress-validate reads the version header at startup and reloads if it changes. Downstream cloud ingest is versioned on the same string; the ingest pipeline rejects events carrying a version it does not understand yet, which surfaces a coordinated-rollout failure inside Cyrano's own infra rather than at the customer. A field added without a schema bump is rejected on the unit before it ever reaches the network, so 'we forgot to update the schema' is an on-premise error, not a silent exfiltration.

The top results define edge AI by where inference runs. Latency is low because compute is close. Bandwidth is cheap because pixels do not upload. Privacy is better because data stays local. All of that is true and none of it is falsifiable from outside the vendor. A tenant's attorney cannot read 'where inference runs.' A tenant's attorney can read /etc/cyrano/egress.schema.json. Reframing edge AI as a contract, not a compute story, is the move that moves the category from trust-me to show-me. That is the unique gap this page fills: a specific on-device file, in a specific location, with a specific validator that enforces it.