Failure has a non-success result and no mode payload. Our adapter substitutes zero for missing data, then renders that as a mode.

There is your invented status. The adapter needs to recognise a successful reply before interpreting the mode. Missing data is not the robot choosing mode zero, even if zero happens to be a valid value elsewhere.

Our learners read a stale value as current. The tiny timestamp didn't rescue it.

Luca, was the timestamp actually described as the last successful read? A time beside a value can also look like the screen's refresh time, which leaves the same misunderstanding.

Just a time. You're right, we hadn't said what happened then.

I've removed the zero fallback in our offline adapter. Captured failures now show unavailable; the last successful mode sits separately with its read time.

Does an unrecognised successful payload also become unavailable, or can its raw value still slip through the old mode lookup?

Harish's case needs its own test. Also test a malformed reply after a good read. The screen must not preserve the old current-mode label just because the new answer was awkward to parse.

Unrecognised payload now produces unsupported response in the harness. The good-then-malformed sequence is still missing. Leaving this as an adapter change under test.

That wording distinguishes a failed request from a response your software cannot interpret. I'd have an intended user explain both screens before deciding whether the distinction is clear enough.