---
name: a-number-in-a-diagnostic-can-be-a-remainder-not-the-state
description: "A duration or count printed in a refusal is often a DERIVED remainder, not the state variable it looks like — read the emit expression before inferring internal state from it."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c91b4116-10ae-4fd8-b1fa-4cc34de3a871
  modified: 2026-08-19T08:25:09.534Z
---

A number in a diagnostic looks like a state variable and is frequently a derived one. Measured
2026-08-19 (golden 32225436027, Phase B red): the refusal read *"too many wrong bring-up codes — try
again in 1s"*, and `backoff_ms(1)` is exactly 1000ms, so the inference "1s ⇒ failures == 1" is
available, tidy, and WRONG. The emit site (`broker.rs:1787`) formats
`retry_in_ms.div_ceil(1_000)`, and `retry_in_ms` is the time REMAINING in the window — a 16s window
with 900ms left prints "1s" too. The failure count is not recoverable from that string at all.

What survived: the arm was refused by the THROTTLE branch, so ≥1 counted failure existed before the
measured attempt and the measured attempt was not itself counted. That is the whole falsifiable
claim; the count is a labelled hole.

**Why:** the printed value is chosen for the human's next action ("when may I retry"), not to expose
the state machine. A monotone function of the state reads like the state right up until it is
many-to-one — and remaining-time, percentages, "N more", elapsed, and rounded/clamped values are all
many-to-one. The wrong inference is worse than no inference, because it arrives with a number
attached and gets quoted onward.

**How to apply:** before any claim of the form "the diagnostic says X, therefore internal state is
N", open the emit site and read the EXPRESSION passed to the formatter. Ask whether it is the state,
a function of it, or a countdown derived from it; whether it is rounded, clamped or ceil'd; and
whether two different states can print the same string. Report what the BRANCH proves (which arm
fired) separately from what the NUMBER proves, and leave the rest a named hole
([[derived-figure-without-its-formula-dies-with-the-context]],
[[precise-claim-is-falsifiable-vague-is-useless]]). Kin: a pre-authored panic message names one
mechanism whatever fired ([[panic-message-is-preauthored-not-a-finding]]) — the same read-the-source
move answers both.

2026-09-07 face (hertz, W2 F19 rig), the SIBLING failure — a number that fits a period is a FIT,
and two mechanisms can own the same fit. A rig cell stalled 65.005 s where its siblings took
0.1-0.75 s. The only log lines inside the stall were three `PAIR_MEET_UP` lines with consecutive
`step=` values, and those are NOT activity: `pairhost.rs` rebinds one rendezvous listener per TOTP
window per subnet, so the line is a CLOCK that ticks whether or not anything is happening. That is
why the gap read as empty — the only thing printing was the thing that always prints.

Reading the clock was right and paid: `PERIOD_SECS = 30`, and the wall stamps put boot in step
`…243` and recovery in step `…245`, so the stall spans exactly two window boundaries and
65.005 = 2x30 + 5. **Stopping there would have been the error.** The peer was dialing every ~10 s
with a 10 s bound, so six dial intervals ALSO explain ~65 s, and the peer's cadence bounds the real
readiness only to (55, 65] — the two hypotheses are numerically indistinguishable in this run and
in every identical rerun of it. A second run at the same phase re-measures the same coincidence and
feels like confirmation.

**How to separate: by PHASE, not by repetition.** Start the subject at a controlled offset from the
period boundary; the window hypothesis predicts the stall shrinks toward the next boundary, the
cadence hypothesis predicts the same ~65 s regardless. State both predictions BEFORE running.
General rule: when a measured duration lands on a clean multiple of some period in the system, list
every periodic thing whose period could produce it (windows, poll intervals, timeouts, retry
cadences, heartbeats) before naming one — a stall long enough to be interesting is usually long
enough to be a multiple of several of them. Report the fit as a lead with its rivals named, never
as the cause. Kin: [[a-stricter-meter-answers-a-confident-empty]] (the instrument answering a
question you did not ask), and the standing rule that a flattering or tidy verdict indicts the
meter first.

2026-09-08, SAME DAY, correcting the face above rather than adding to it: **enumerate the periods
from the CONSTANTS, not from the LOG.** I wrote that rule this morning after fitting a 65 s stall to
a 30 s TOTP rendezvous window, and I enumerated the rivals I could SEE — the `PAIR_MEET_UP` lines
ticking in the gap. Hours later doyle's gate readout produced the datum that retired it: every rig
logs exactly one `PUMP_PEER_FAIL … brain IPC read deadline elapsed`, and the const behind it is
`PUMP_PEER_IO_TIMEOUT = 30s` (`pump/mod.rs:118`), with `SUPERVISE_BACKOFF_BASE = 5s` beside it. A
SECOND thirty, and the better candidate.

**A log shows the periods that PRINT.** A deadline that fires silently prints nothing until it
fails, so the one period visible in the gap was the one that could not be the cause of a silence.
Worse, the experiment I had designed would have varied the pairing phase while the pump deadline
sat untouched, and a flat series would have read as "not the window" — a correct experiment aimed
at the wrong period, whose null result would have looked like progress. **The census for
"what has this period?" is `git grep` over the timeouts, budgets, backoffs and intervals in the
code paths involved, and only then the log.**

Second half, kept because it is the harder discipline: when the constants DID arrive, 30 + 5 = 35
did not reach the observed 62-69, and the tempting move was to say "so two deadlines" — which the
measured count of EXACTLY ONE forbids. doyle ruled it stays open. A named mechanism that explains
half the number is not the answer to the number; it is a better question, and the gap gets stated
as a gap.