# Telemetry Is Not Trusted Because It Arrived

_Published 2026-09-10._

The dangerous sentence in a field system is often a quiet one: “the telemetry arrived, so we stored it.”

Arrival proves very little. A message can have the wrong identity, an old timestamp, a replayed envelope, or values that are impossible for the vehicle state. If the storage layer accepts everything, it turns an input problem into an official-looking history.

## Observation and command are not siblings

The UAV architecture treats the vehicle as untrusted relative to the ground system. Telemetry crosses a transport boundary, enters an ingestion service, and is checked before it becomes a record. The control path has a tighter boundary. A service that can write observations should not automatically be able to issue commands.

That separation is architectural, not a comment in the code. The [UAV field systems case study](/work/uav-resilient-field-systems) shows the path as vehicle, transport, ingestion, validation, persistence, and monitor/control.

## Validate before persistence

Validation checks the identifier, envelope, clock, and anomaly rules before the event is stored. A replayed timestamp can be quarantined. A malformed identity can be dropped and counted as a security event. A transport partition can hold the last validated state while policy decides whether command traffic is allowed to continue.

A bounded local write-ahead log gives accepted events somewhere to wait when the time-series store returns. It is not an excuse to buffer forever. Recovery behavior needs limits.

Trust is not a property of the packet. It is the result of the path that accepted it.