A vehicle fleet uploads terabytes of sensor data daily over unreliable networks and models must be updated over the air. How should edge filtering, resumable uploads, prioritisation, staged model rollout and on-device rollback be designed?

The upload problem: filter at the edge, because the network is the constraint

A fleet generates orders of magnitude more data than any network can carry, so the question is not how to upload it but what to upload.

• On-device triage. The vehicle decides what is interesting: disengagements, interventions, near-misses, detection disagreements between sensors, novel conditions, and anything where the model's confidence was low. The overwhelmingly common case — an uneventful stretch of familiar road — is the data with the least training value, and discarding it is the single largest saving.
• Targeted collection campaigns, where a query is pushed to the fleet — "upload clips matching this scenario" — so collection is driven by what the training pipeline currently needs rather than by a fixed policy.
• Summarise on-device: metadata, embeddings, statistics and detections uploaded always, with full sensor data only when triggered.
• Compression and format selection at the edge, since bandwidth is the binding constraint.

Resumable, prioritised upload

• Chunked uploads with resumption, because connectivity is intermittent by definition and restarting a multi-gigabyte upload on every disconnection means it never completes.
• Priority classes, so safety-critical events upload before routine collection, and the routine backlog yields.
• Network-aware policy: full uploads on unmetered connections at rest, metadata only on cellular — a cost decision as much as a technical one.
• A bounded on-device buffer with an explicit eviction policy, since storage is finite and something must be discarded when it fills. That policy is a data-value decision and should be made deliberately rather than by whatever the buffer does when full.
• Deduplication and back-pressure, so a fleet-wide event does not produce a synchronised upload storm from every vehicle simultaneously.

Model rollout, where the stakes change

The blast-radius reasoning is the same as any staged rollout and the recovery cost is far higher, because a failure on a physical device may prevent remote remediation entirely.

• Shadow mode first: the new model runs alongside the current one, its outputs recorded and compared, influencing nothing. This is traffic shadowing applied to a fleet, and it is the highest-value stage.
• Staged rollout by cohort — internal fleet, volunteers, small percentage, geography by geography — with automatic halt on regression signals.
• Bake time spanning real conditions, since a model that fails in heavy rain or low sun needs the rollout to encounter those.
• Segmented comparison rather than aggregates, because a regression affecting one condition, one hardware revision or one region is invisible in a fleet-wide average.
• Never update while the function is active, with the update applied at a safe moment and verified before use.

On-device rollback, which is the decisive control

If a bad update prevents the device from communicating, no server-side mechanism can fix it — and remediation becomes physical, at fleet scale, which is a logistics problem rather than an engineering one.

• The previous known-good version retained on device, always.
• Automatic local revert on repeated failure, health-check failure or watchdog trigger, without needing to reach a server.
• Dual-bank or A/B partition updates, so the new version is written to an inactive partition and activated only after verification, with the old partition intact.
• A verified boot chain, so a corrupted update does not produce an unrecoverable device.
• An independent recovery channel where the economics justify it.

The governing principle: the cost of a failure is its blast radius multiplied by its recovery cost per unit. A wide radius with cheap recovery is an incident; a wide radius on physical devices where recovery requires a person to attend is a different category of event entirely, and it justifies blast-radius controls an order of magnitude stricter than a server-side deployment.