The on-device inference guarantee is the part of the Occivar architecture that makes every other guarantee load-bearing. It is not a marketing slogan and it is not a deployment configuration. It is a hardware choice, a model choice and a network topology, and removing any of the three breaks the privacy answer.
01 · WHY "ON-DEVICE" IS NON-NEGOTIABLEWhy "on-device" is non-negotiable
If the raw frame leaves the sensor, every downstream guarantee becomes a policy guarantee. Retention, encryption, access control, FOI exposure: all of them are arguments the legal team has to win on someone else's terms. If the raw frame never leaves the sensor, none of those arguments are necessary, because there is no frame to govern.
The platform's privacy-by-design answer rests on this single property. Edge AI is what makes it true.
02 · THE HARDWARE CLASSES THE PLATFORM SUPPORTSThe hardware classes the platform supports
The platform runs on three hardware classes by default:
- Jetson-class NPUs (Jetson Orin Nano and up). The reference hardware for new deployments. Low power, sufficient compute for the model at 30 FPS, well-supported toolchain.
- Coral-class TPUs. A lighter-weight option for high-zone-count deployments where per-sensor power budget matters more than peak FPS. Quantised model variant.
- Raspberry Pi 5 + accelerator. The cost-optimised configuration for non-safety-critical zones. Same model, lower frame rate, longer write cycle on the counts.
Choice of hardware is deployment-driven: the heuristic is power available, FPS required for the zone's geometry, and unit cost across the install. Cost-per-zone is below the procurement threshold for most facilities.
03 · LATENCY, AND WHAT IT MEANS IN PRACTICELatency, and what it means in practice
End-to-end latency from frame capture to count emitted on the dashboard is under 60ms on the reference hardware. That figure includes inference, post-processing, and the network hop to the platform. Sub-second alerting is the design target; sub-100ms is what we measure.
Latency is operational, not just technical: a threshold crossing that takes four seconds to surface is one that ops responds to four seconds later. For most building use cases that delay is invisible. For crowd-safety use cases it is the difference between a routing nudge that works and a bottleneck that has already formed.
04 · WHAT THE MODEL DOES AND DOES NOT DOWhat the model does and does not do
The on-device model produces:
- A per-zone count of people, refreshed every frame.
- A per-zone density figure, computed against the calibrated capacity.
- An anonymous dot position within the zone, for the dashboard's visualisation only.
The model does not produce:
- Face detection (the model has no head for it).
- Demographic inference (no head, no training data, no shipped weights).
- Identity or re-identification across frames (we don't ship the embeddings).
Each of these is a capability we have not built, not a capability we have disabled. The distinction matters under audit.
05 · NETWORK TOPOLOGYNetwork topology
The sensor's outbound network carries the count, the density and the audit metadata: no frames, ever. There is no inbound video path. The sensor accepts firmware updates over an authenticated, signed channel and pushes counts over a signed, retryable transport. Operating in a constrained network is normal: most building deployments give the sensor a dedicated VLAN, and the platform is designed to tolerate a thirty-second outage without losing counts.
06 · HOW EDGE AI FITS THE RESTHow edge AI fits the rest
Edge AI is the part of the architecture that the rest of the platform depends on. Occupancy analytics reads what the edge model emits. Alerts and reports operate on the same counts. Privacy-by-design is the structural promise that the edge model is what makes possible.
If your last occupancy conversation got stuck on what the camera might be doing, the edge AI conversation is the one that ends it.