Edge AI reference workloads #

These five workload shapes test whether an edge inference application can produce an operational customer outcome, not merely load a model. Four are acceptance blueprints for customer-owned software. The model-free video analytics example is the only supplied workload in this set.

Use the same end-to-end proof for each workload:

input -> local result -> typed Product event -> Edge Process -> typed OEM Command -> offline outcome -> reconnect -> fleet and customer evidence

The deterministic reference-workload-fixtures.json defines one event and expected offline outcome for each shape. It is a documentation test fixture, not a Model registry, inference-runtime, or Software upload manifest.

1. Camera object detection #

Status: acceptance blueprint. No detector or managed inference runtime is supplied.

Provide a customer-owned camera source, object detector, preprocessing, and postprocessing. Emit a typed vision.object_detected event with the source timestamp, model digest, class, score, bounded regions, execution target, and fallback state.

Qualify:

CPU execution and at least one real accelerator path;
explicit CPU fallback, including its latency and thermal envelope;
stale input, queue saturation, model-load failure, and runtime restart;
bounded event rate rather than one cloud upload per frame;
no assertion that the reference model is accurate for an unqualified scene.

Project source age, inference rate, p95 latency, errors, and fallback state into bounded operational telemetry. The Customer Portal can show an ordinary Product event/history surface only after the OEM has designed and permitted that Product Application view.

2. Vehicle and plate workflow #

Status: a shipped model-free plate/OCR path plus an acceptance blueprint for semantic vehicle detection.

Do not pretend one model solves the workflow. Compose:

an optional customer-owned semantic vehicle detector;
the model-free plate and constrained OCR path;
a typed vehicle.detected or edge.vision.code_read event;
an Edge Process that checks local authority and invokes a typed gate.request_open simulation;
the OEM handler that enforces the actual gate safety boundary;
reconnect and audit reconciliation.

The model-free path may report a plate-shaped OCR result as evidence of a likely vehicle, but object type remains unknown. Motion contours are not semantic person or vehicle detections.

Use the downloadable edge-ai-offline-process.json as the deterministic offline Process example.

3. Occupancy and counting #

Status: acceptance blueprint. No people detector or counting model is supplied.

Keep frame processing local. Publish a bounded occupancy/count state only when the value changes, at a defined summary interval, or on a meaningful threshold transition.

The event must distinguish:

known from unknown;
zero occupancy from no fresh source;
current count from a stale last-known count;
normal execution from CPU fallback or degraded inference.

Never derive people count from model-free motion blobs. Test source loss, crossing in both directions, restart with local aggregate state, and a full offline event queue.

4. Visual inspection #

Status: acceptance blueprint. No anomaly or classification model is supplied.

Use a customer-owned classifier or anomaly model and emit one of pass, fail, or uncertain. The Process must route uncertain to an operator or a safe product state. It must not silently turn low confidence into pass or fail.

Where the product captures a low-confidence image:

capture is opt-in;
storage is customer-owned and bounded;
the Product event carries metadata or a reference, not image bytes;
crop, masking, retention, visibility, and export are defined before release;
later operator feedback does not mutate the original inference event.

No Dataplicity evidence or feedback service is currently available, so qualify that path in the OEM application and storage system.

5. Non-vision sensor inference #

Status: acceptance blueprint. No sensor model or managed runtime is supplied.

This workload proves the architecture is not camera-specific. Feed a bounded window of numeric vibration, current, pressure, acoustic-feature, or temperature data into a customer-owned portable runtime. Emit sensor.classification or sensor.anomaly.

An offline Process can use the typed result to request a safe OEM action such as reducing a simulated duty cycle or opening a maintenance task in local state. The device handler remains authoritative for physical limits.

Qualify:

window identity, sampling gaps, units, and clock validity;
deterministic preprocessing and model digest;
CPU path and the intended accelerator path, if any;
inference latency, queue depth, dropped windows, errors, and output rate;
replay/idempotency across restart and reconnect;
unknown when input quality is insufficient.

Run a common failure matrix #

For every model-backed blueprint, test at minimum:

Failure	Required observable outcome today
Incompatible device	Keep it out of the targeted tag cohort and record the qualification failure
Device offline during rollout	It remains outside success counts until its actual Software state and health are verified
Model digest mismatch	Customer-owned startup validation blocks inference and reports unavailable
Accelerator runtime missing or reset	Report the specific failure; use CPU only when explicitly configured and visible
Model load failure	Report unavailable and preserve the known-good Software path
Input stale	Report unknown/unavailable rather than zero or normal
Queue saturation	Apply the declared drop/backpressure rule and publish bounded counters
Runtime restart	Restore bounded local state and avoid duplicate Product outcomes
WAN loss	The Edge Process continues only with local data and typed capabilities
Duplicate result	Deterministic event/domain identity prevents another physical side effect
Evidence spool full	Customer-owned quota and eviction policy produce an explicit state
Canary regression	An operator pauses cohort expansion; there is no automatic AI rollout gate today
Reversal	A newer known-good Software Build restores the qualified model/runtime combination

Record acceptance evidence #

For each supported hardware path, retain:

Device Class, architecture, board, OS, and agent version;
model, model digest, runtime, driver, and accelerator versions;
container digest and Software Build;
source fixture identity and expected typed event;
online, offline, restart, saturation, fallback, and reversal results;
measured latency/resource bounds without extrapolating semantic accuracy;
the exact customer-visible result and operator decision.

Deterministic fixtures are suitable for CI wiring and failure semantics. Real accelerator hardware is still required to qualify vendor runtime, device access, thermals, and performance.