Sensor Input Validation

Software teams reliably validate user input and reliably trust sensor input. The asymmetry is unjustified: sensors drift, saturate, fail toward plausible mid-range values, and report confidently from positions the device cannot physically occupy.

A reading that is missing is a visible problem. A reading that is well-formed and wrong is an invisible one, and it propagates into every decision downstream.

What plausibility checking covers

• Range, against physically possible values rather than against the data type.
• Rate of change, since a temperature that moves twenty degrees in a second or a position that implies impossible speed is a sensor fault, not an event.
• Cross-sensor consistency, comparing readings that should agree — the strongest available check and the one most often absent.
• Staleness, since a sensor repeating the same value indefinitely is usually stuck rather than stable.
• Physical constraints, such as a vehicle reporting a position in the sea or a meter reading that decreases when it cannot.

Implementation patterns

• Validation at ingestion, before the reading enters any store that other systems read.
• Flag rather than discard, retaining the raw reading with a quality marker so the original evidence survives a later reinterpretation. Record what was observed separately from what was concluded.
• A distinct state for sensor fault, not a substantive value, so downstream consumers can distinguish "we do not know" from "we know it is this".
• Degrade to a usable mode rather than blocking. If the system cannot verify something, the work still has to happen — capture what is known, mark it provisional, and reconcile later.
• Continuous reconciliation against physical checks, since drift between recorded and actual state is guaranteed rather than exceptional.

Industry example

Logistics, micromobility and field-operations platforms all discover the same set of failures, and none of them are software defects. GPS drifts in urban canyons and reports positions inside buildings. Scanners misread damaged barcodes into valid-looking codes. Humans deviate from the process because the process does not fit reality — the address is wrong, the recipient is absent — and a system with no path for the real situation gets worked around, at which point the workaround becomes invisible to the platform.

The architectural conclusion is that exceptions must be first-class. Every real operation has a long tail of unusual cases, and a system that handles only the happy path pushes all of them into phone calls and spreadsheets where nothing can be measured or improved.

Failure scenarios

• Sensor readings trusted as ground truth, propagating faults into every downstream decision.
• Invalid readings discarded silently, destroying the evidence needed to diagnose the fault.
• No cross-sensor checks, missing the faults that single-value range checks cannot see.
• Stuck sensors read as stable, which looks like the healthiest possible signal.
• No exception path, driving real operations into invisible workarounds.

Trade-offs

Aggressive validation rejects genuine unusual readings — a real extreme value flagged as implausible is a missed event, and in safety contexts that can matter more than accepting a bad one. The thresholds are a domain judgement, not a statistical one.

The resolution is generally to flag rather than reject, keeping the reading and the doubt together so a consumer can decide. That preserves the evidence for both cases and moves the decision to whoever has the context to make it.

Interview question

"A delivery vehicle reports a GPS position two kilometres from its previous fix, thirty seconds later. What should your system do with that reading, and what should it never do?"