Edge Triage

A large fleet of sensor-equipped devices produces data at a rate that no network, and no storage budget, can absorb. The design question is therefore never how to upload everything; it is what to upload.

Edge triage moves that decision onto the device. The device evaluates its own data against criteria — novelty, uncertainty, disagreement between sensors, an intervention, a safety-relevant event — and transmits the small fraction that carries information, along with summaries and metadata for everything else.

Why it matters

The data's value is extremely unevenly distributed. A recording of a familiar road in good conditions with every model confident and correct contributes almost nothing to training or diagnosis; a disengagement, a near-miss, an unusual object or a case where two sensors disagreed contributes a great deal.

Uploading uniformly therefore spends the entire bandwidth budget on the least useful data, and the interesting cases are crowded out by volume rather than by any decision.

The second reason is economic and constant: bandwidth on cellular links is a recurring per-device cost across the whole fleet, so triage is not an optimisation but the condition under which the system is affordable at all.

Implementation patterns

• Trigger criteria evaluated on-device: model confidence below a threshold, disagreement between redundant sensors, an intervention or manual override, an anomaly against expected behaviour, a rare classification.
• Targeted collection campaigns, where a query is pushed to the fleet — "upload examples matching this scenario" — so collection is driven by what the training pipeline currently needs rather than by a fixed policy set months earlier.
• Always-upload summaries: metadata, embeddings, detections and statistics for every unit of operation, so the fleet's aggregate behaviour is visible even where raw data is not retained.
• A bounded local buffer with a deliberate eviction policy, since storage fills and something must be discarded — which is a data-value decision that should be made explicitly rather than by whatever the buffer does when full.
• Priority classes on upload, so safety-relevant events precede routine collection and the routine backlog yields.
• Network-aware policy: full uploads on unmetered connections at rest, metadata only on metered links.
• Chunked resumable transfer, because restarting a large upload on every disconnection means it never completes.
• Jitter and back-pressure, so a fleet-wide event does not produce a synchronised upload storm.

Industry example

Fleet-scale autonomous and driver-assistance programmes operate this way of necessity: the vehicle decides what is interesting and the fleet is queried for specific scenarios, because the alternative — uploading continuous sensor streams from a large fleet — exceeds any plausible network and storage budget by orders of magnitude.

The same structure appears wherever devices produce more than can be transmitted: industrial telemetry, medical monitoring, and observability agents that sample locally rather than shipping everything. It is the same reasoning as non-uniform telemetry sampling — keep all the errors and slow requests, sample the routine heavily — applied where the bandwidth constraint is physical rather than financial.

Failure scenarios

• Uniform uploading, spending the budget on the least informative data.
• Trigger criteria fixed at deployment, so collection cannot follow what the models currently need.
• No summaries for non-uploaded data, leaving the fleet's aggregate behaviour invisible.
• An unbounded or undefined buffer eviction policy, so the data discarded under pressure is arbitrary.
• Non-resumable uploads, which never complete on intermittent links.
• Synchronised upload after a fleet-wide event, saturating ingest.
• Triage criteria that systematically exclude a failure mode, so the model never sees the cases it is worst at — a self-reinforcing blind spot, and the most damaging failure of the pattern.
• No sampling of the ordinary case at all, which removes the baseline needed to detect distribution shift.

Trade-offs

Triage discards data permanently, and the criteria encode a belief about what will matter. When that belief is wrong, the evidence is simply gone — and the case for which the belief is most likely to be wrong is the novel failure mode nobody anticipated, which is precisely what the collection exists to find.

The mitigation is partial and important: retain a small random sample of ordinary data alongside the triggered set, so the baseline distribution is measurable and shift is detectable. That costs bandwidth for data believed to be uninteresting, which is exactly what triage set out to avoid.

The trade is permanent loss of unselected data in exchange for a system that is affordable to operate. The constraint is not negotiable at fleet scale, so the engineering question is only how good the selection is, and how much random baseline is retained alongside it — and reviewing the criteria against what the models actually get wrong is what keeps the selection honest.

Interview question

"Our fleet produces a hundred times more data than we can upload. Tell me how you decide what to keep, then tell me how you would find out that your criteria are systematically missing something important."