A model can pass its offline evaluation and still fail as a product. At the edge, the shipped system includes the converted model, runtime, accelerator, enclosure, sensors, update mechanism, operators and recovery path. The useful question is therefore not only does the model work? It is which evidence shows that this exact system keeps working inside its intended operating boundary?
This playbook uses four failure classes as a pre-mortem. They are not a statistical claim about every incident, and they are not mutually exclusive. They are a compact way to expose expensive gaps before a pilot becomes a fleet.
Source status — reviewed 2 August 2026. The technical mechanisms below are anchored in primary documentation from ONNX Runtime, NVIDIA, NIST, TUF and Uptane. Any thresholds, durations and acceptance limits must be set for the specific product; this article deliberately does not invent universal numbers.
1. The deployed artefact is not the evaluated artefact
What changes
Training checkpoints are routinely converted, fused, quantised or compiled for a target accelerator. The runtime may partition the graph differently by device. Pre-processing and post-processing code may also change between the notebook and the embedded application. The shipped object is therefore a chain of artefacts, not just a weight file.
ONNX Runtime's quantisation documentation is explicit that quantisation is not lossless and can affect accuracy. It provides calibration and debugging mechanisms, while its main documentation states that teams remain responsible for validating accuracy, performance and suitability for the intended use.
How the failure appears
- aggregate performance looks acceptable while an important class or operating condition regresses;
- an unsupported operator falls back to a slower execution provider;
- pre-processing differs in colour order, resize, normalisation or sensor units;
- the model hash is correct but the runtime, calibration set or compiler version is not the one that was approved.
Verification gate
Evaluate the deployable bundle on the target device. Bind the following into one release record:
- source checkpoint and hash;
- conversion/quantisation configuration and tool version;
- calibration/evaluation dataset versions and provenance;
- pre- and post-processing implementation;
- runtime, backend, driver and target-device identity;
- class-, condition- and consequence-specific results;
- the acceptance decision and named owner.
Compare intermediate outputs where the toolchain permits it. If a sensitive layer cannot meet the task acceptance bar after quantisation, retain greater precision for that part or choose a different target. Do not average a safety- or quality-critical class out of the decision.
Evidence to keep
A model card is not enough. Keep the signed bundle manifest, toolchain bill of materials, conversion log, evaluation report, known limitations and rollback target. The production identity should resolve to all of them.
2. The target misses its sustained operating envelope
What changes
A development kit on an open bench is not the deployed thermal system. Enclosure, ambient temperature, airflow, mounting, dust, power supply and co-resident workloads determine the sustainable clocks and throughput. Peak performance can therefore be the wrong purchasing metric.
NVIDIA's Jetson power and performance documentation describes power modes, thermal management and software-visible controls. The important general lesson is not a Jetson-specific threshold: power and thermal controls dynamically constrain performance, so the target must be measured under its real constraints.
How the failure appears
- latency or frame deadlines degrade after warm-up;
- the queue grows even though short tests passed;
- voltage or thermal events trigger throttling, resets or unavailable accelerators;
- a co-resident process creates memory pressure or steals compute during a critical window.
Verification gate
Define an operating-envelope matrix before hardware selection:
| Variable | Boundary to test | Evidence |
|---|---|---|
| Ambient and enclosure | Minimum/maximum intended conditions and worst credible cooling state | Instrumented chamber or representative enclosure run |
| Power | Nominal, brownout and restart behaviour | Power trace, fault injection and recovery log |
| Workload | Peak request/frame distribution plus co-resident services | Queue, latency and dropped-work telemetry |
| Duration | Long enough to reach steady thermal behaviour | Sustained trace, not a short peak result |
| Degradation | What the product does when the target is exceeded | Load shedding, safe state and operator message |
The acceptance metric is the sustained floor inside the declared envelope, with a defined degradation path—not the highest number observed.
Evidence to keep
Store the enclosure/BOM revision, firmware and power mode beside the run. A thermal result cannot be reused after a heatsink, fan policy, enclosure or workload changes without assessing whether revalidation is required.
3. The field input leaves the validated boundary
What changes
Physical systems do not receive a stationary stream. Sensors age, move, get dirty or get replaced. Lighting, weather, surfaces, process recipes, firmware and human behaviour change. The model may be unchanged while the relationship between input, context and required decision changes.
NIST's AI RMF Core calls for testing in conditions similar to deployment, documenting limits on generalisation and monitoring system behaviour in production. NIST's 2026 report Challenges to the Monitoring of Deployed AI Systems distinguishes functionality, operational and other monitoring categories and highlights real barriers such as fragmented logs and performance degradation. It does not offer a universal drift score—and neither should a product team.
How the failure appears
- confidence shifts without a clear operational alarm;
- operator overrides, abstentions or unknown-class events rise;
- one site, sensor revision or product variant diverges from the fleet;
- the system remains internally healthy while the physical measurement is no longer trustworthy.
Verification gate
Build monitoring around the failure consequence, not around whichever metric the MLOps platform exposes by default. At minimum:
- specify the intended input and operating boundary;
- log sensor identity, calibration/firmware and relevant context with each decision or aggregate;
- monitor data quality, system functionality, operator intervention and outcome signals separately;
- predefine the review, fallback and data-capture action for each alarm;
- test detection with known shifts and sensor faults;
- prove that the safe/degraded mode works when monitoring itself is unavailable.
A distribution-distance statistic can be useful, but it is not evidence of harm by itself. Pair it with product outcomes and human feedback. Likewise, a stable input distribution does not prove the model remains correct.
Evidence to keep
Retain the monitoring specification, alarm rationale, response owner, field-event samples, override/abstention analysis and decisions about recalibration, retraining or withdrawal. Version those records against device, sensor and model identities.
4. The fleet cannot update or recover safely
What changes
A lab team can reinstall a broken machine. A distributed device may be remote, intermittently connected or physically costly to reach. Model updates also interact with application code, schemas, configuration and cached state. A downloaded image is not the same as a product recovered to a known-good state.
The Update Framework documents threats including arbitrary software, rollback and freeze attacks. Uptane applies a compromise-resilient update design to vehicle ECUs, including metadata and image verification. A/B root-file-system schemes such as the one described in Mender's documentation illustrate one recovery pattern; they do not remove the need to validate application state and hardware variants.
How the failure appears
- a valid but incompatible combination of model, runtime and application reaches a device;
- power loss leaves no bootable or operational image;
- a health check validates the operating system while the inference path is broken;
- rollback restores binaries but not a compatible configuration or local database;
- a rollout reaches too much of the fleet before a field-only fault is visible.
Verification gate
Treat update and recovery as a product capability with its own acceptance tests:
- signed metadata and artefacts, trusted key roles and rotation/revocation procedure;
- hardware- and dependency-aware compatibility manifest;
- atomic installation or equivalent interruption-safe design;
- application-level health criteria, not only successful boot;
- automatic rollback or an explicitly tested recovery route;
- staged cohorts with stop conditions and an authorised decision owner;
- fault injection for interrupted download, interrupted installation, invalid signature, incompatible bundle, failed health check and unavailable backhaul;
- a field-service path for devices that cannot recover remotely.
Evidence to keep
Keep the release decision, signatures, cohort progression, health results, stop/rollback events and device state transitions. The update ledger should answer which device received which complete bundle, why it advanced, and what recovery path remains.
One production-readiness review, four evidence packets
These failure classes should converge in a single system decision review:
| Boundary | Decision question | Minimum packet |
|---|---|---|
| Artefact | Is the shipped computation the one we approved? | Bundle identity, target-device evaluation, limitations |
| Operating envelope | Does it meet the sustained requirement in context? | Thermal/power/workload traces and degradation test |
| Field input | Will we know when the validated boundary changes? | Monitoring specification, injected-shift tests, response playbook |
| Fleet lifecycle | Can we change and recover it without losing control? | Signed update, staged rollout, rollback and field-recovery tests |
A gate passes only when the evidence, acceptance threshold and owner are explicit. The demo worked is not an entry in any packet.
The system-level conclusion
Edge AI failures are often integration and lifecycle failures expressed through a model-shaped interface. That is why product ownership matters: somebody must connect customer consequence, model evaluation, hardware envelope, operations and recovery before the next commitment.
Use this playbook as a pre-mortem, then tailor the thresholds and evidence to the intended use, sector standards and applicable law. For a structured review, the Physical AI Product System and Product Decision Review turn these packets into an explicit advance, hold, redirect or stop decision.
