So return validity separately from the value. Not a made-up status code for failure?

Yes. A substitute number can look entirely believable, which is a rather efficient way of hiding the original fault.

And don't accept a container merely because its value-shaped field exists.

Jamie's point belongs at that boundary too: documented success indication, expected structure and value interpretation. Use the installed SDK's documentation rather than transferring the earlier adapter's field assumptions.

I've captured valid and failed replies from this version. Their payloads alone aren't enough to distinguish success.

Use those captures in a small offline test before another dashboard session. Include malformed input and the transition from a good reading to a failed request.

Does a failure leave the previous good reading looking current?

It did. Now failure marks it unavailable; the previous reading is separately labelled with its timestamp.

Offline cases pass. Approved read-only comparison also matches the controller indication. Thanks, the stale-reading check caught another misleading screen state.

Keep those captured examples with the version record. Whoever updates this training laptop next should be able to rerun the boundary checks without reconstructing your investigation.