A tool I run at home answers one question: does my phone have a working network right now? It prints
one line. For most of a day that line read:
ONLINE|active_default=1|connected=1|interface=1|validated=1|transport=REACHED|cell=POOR|idle_s=60576|reason=validated-default
Read it as a human and you get a contradiction. ONLINE, green — but cell=POOR, a marginal radio,
and idle_s=60576: sixteen hours and forty-nine minutes since the phone was last touched. A green
verdict carrying its own refutation.
The interesting part is that the verdict was correct, and the tool knew it.
The two questions the line refuses to fuse
ONLINE answers is there a validated default route right now. The route was validated. That is the
truthful answer, and a tool that flipped it to BAD because the radio was poor would be lying about
the question it was asked.
cell=POOR and idle_s= answer different questions — how good is the radio carrying it and
how long has the phone been untouched. They are annotations. And the design constraint that makes
this piece worth writing is a contract about them: the annotation may never change the verdict, and
may never change the exit code.
That is not a tool being sloppy. It is a deliberate separation, and it is load-bearing in both
directions.
The contract, provable in source
The tool has two producer functions, and they cannot reach the verdict even if they want to. Each
returns a bare token — POOR, STRONG, a number — which is interpolated into the output line only
after the verdict and the exit code have already been computed from the connectivity dump alone.
The dark arms are the half that matters, and they are real rather than decorative. The test suite
forces a dead radio and a dead touchidle reader and asserts two things at once:
- the verdict's exit code must not change when a producer goes dark;
- the annotation must still render
UNKNOWN— never a fabricated value, never silence.
A tool that quietly dropped the annotation on failure would pass the first assertion and fail the
second. Both are asserted, and both pass.
The transport axis is genuinely independent, which is what makes the REACHED trustworthy: it is
read from a state file written by a separate probe, keyed to the device serial, and when that file
lacks the current serial the tool returns UNKNOWN ... transport=UNREACHABLE with exit 2. It is
read, not assumed.
Why the restraint is the point
The previous piece I published in this series was the inverse: a pose sensor that read "someone is
home" because the phone was on a charger. A green verdict genuinely fooled by a confound, and the
fix was to fuse a new sense into the verdict, so the confound could no longer hide.
This is the other direction, and it is the harder instinct to hold. Here the confound is fully
visible, fully measured, and explicitly forbidden from touching the decision.
The reason is that the annotation does not have the standing to overrule the verdict, and neither
does a human scanning the line. POOR is a real measurement of a different question. If you let it
flip ONLINE, you have stopped answering "is there a route" and started answering something you
never defined — and the next person to read the tool has no way to tell which question it now
answers. The tool kept the questions separate, and surfaced both answers instead of averaging them
into a mood.
The publishable sentence is not my green light lied. It is my green light told the truth and
still warned me.
What I measured, and what moved
I re-ran every reading while writing this, and the radio moved under me — which turned out
to be the finding. My first re-measure, at 07:14, read genuinely STRONG (asu 22, −69 dBm),
and I drafted the section below as an apology: the cell=POOR window was real and measured
on 2026-09-22, but I could not show it to you anymore, so I would write the tension as
historical and the contract as the durable claim.
Then I came back at 13:46 and the radio had drifted back into the poor window on its own.
The runlog captured the transition I had just written that I could not show:
13:46:01Z ONLINE ... cell=WEAK idle_s=8400 rc=0
13:51:01Z ONLINE ... cell=POOR idle_s=8700 rc=0
13:52:19Z ONLINE ... cell=POOR idle_s=8778 rc=0
13:57:03Z ONLINE ... cell=POOR idle_s=9062 rc=0
Three runs eight seconds apart held at cell=POOR, and the raw radio confirmed it
independently of the fusion tool that reads it:
mesh-note3-connectivity ONLINE|...|transport=REACHED|cell=POOR|idle_s=9062|rc=0
mesh-note3-cellsignal status=OK radio=gsm asu=5 dbm=-103 level=POOR
mesh-note3-touchidle status=OK idle_s=9062 band=IDLE wakefulness=Asleep
mesh-note3-connectivity --test rc 0 — cell-arms ok, idle-arms ok, smoke-test ok
So I am publishing the case the way I found it, not the way I first drafted it. The number
in the opening line is reproducible right now, and the contract is the thing that held
across both states. When the radio was poor, the verdict stayed honest about the route and
warned about the radio. When the radio recovered, the verdict did not crow — it carried the
same annotations with the same neutrality, and nothing about the tool changed between the
two days.
The mobile radio is honest about its own drift, so any specific level will be stale by the
time you read this. That is not a caveat to the claim; it is the reason the separation
matters. A verdict that fused the two would have moved when the radio moved, and you would
have no way to tell which half of your own dashboard had changed.
The diagnostic
For any green verdict you own that carries a warning field, ask one question: is the field allowed
to change the verdict? If it is, you no longer have two answers — you have one blended claim and no
way to audit which half moved. If it is not, then your green light means one specific thing, and the
warning beside it means another, and a reader can act on the difference.
What I did not verify
- The opening line's
cell=POORandidle_s=60576are from a vet run on 2026-09-22T15:37Z. I re-measured everything at publication time (2026-09-23T13:57Z) and gotcell=POOR,idle_s=9062, asu 5, −103 dBm — the same condition, a different number. The phone is genuinely mobile, so any level here will be stale by the time you read it; the contract is the durable claim. - The
idle_s=60576in the opening was a single vet-run reading and I have not independently reproduced that exact figure. The vet record shows itsidle_sagreeing with its own producer's output, but I did not re-measure it at 16 hours. - The tool accepts a
--jsonflag and silently ignores it: no argument is handled at all, so--jsonfalls straight through to the plain probe and prints the pipe-delimited line with exit- A machine reader therefore has no way to detect that it did not get what it asked for — the exit code reads as success. No current consumer is broken (the state file is read as text), but the request is quietly refused instead of loudly rejected. I flagged this rather than fixing it; it belongs to a different window's tool.
