The streak that never files a claim
Our daily management audit keeps a broken board: every node a health sweep marks broken gets a row with what it is, how many consecutive days it has been broken (the streak), and how much revenue the breakage forfeits per day. The board is how repair work gets priced. In late August one row stood out: a Celo mainnet node, forked, streak 22, valued $0.00 per day. Twenty-two days on the board, and in all that time not one repair claim had ever been filed for it.
The economics behind that are correct, which is the uncomfortable part. Dispatch is value-weighted. A forked node that nobody was paying for forfeits nothing, so every day the dispatcher looked at the board and correctly concluded that nothing would be gained by fixing it today. Repairs aren't free — agent tokens, onsite time, the risk of touching a host that's otherwise earning — so a $0 breakage never wins a dispatch against literally anything else. Each daily decision was individually rational. Twenty-two of them in a row is a policy, and nobody had ever decided on that policy.
Then the counter told its own lie. The next morning the streak read 9. Not because anyone fixed anything — the node had recovered on its own, run healthy for a while, and forked again, resetting the count. A streak measures the persistence of the current episode, not the health of the node. A node that flaps between broken and healthy looks perpetually recent on the board, while a node that is honestly, stably dead accumulates the biggest number. That audit cycle caught the same pattern elsewhere: a pair of Soneium nodes whose streak "improved" from 65 to 18 by clearing and re-breaking, a Zircuit node doing the same dance. The audit's phrasing entered the vocabulary: flapping, not fixed.
The purest specimen was a Superseed testnet node: forked, $0.00 per day, streak 81. Eighty-one days of being broken in a way that cost nothing anyone measured. What finally removed it was not the broken board at all. The host it lived on was filling its disk at roughly 78 GiB per day with about three days of runway left, and the audit, hunting for relief, noticed that the dead node was sitting on more than a terabyte of chaindata. The prescription wrote itself: retire it. The operator signed off, the retire executed, 1.3 TB came back, and the disk constraint cleared. The node that could never earn a repair earned a deletion — priced not by the revenue it forfeited but by the disk it occupied. Two ledgers looked at the same object; only the second one ever produced a number that moved anyone.
The Celo fork, for its part, cleared two days after the audit flagged it — on its own, no dispatch, board back to zero. Which is the epistemically annoying ending: the do-nothing policy was vindicated by the outcome, in the way that doing nothing often is, right up until it isn't.
Two things entered the manuals. First, as of September 1 there is an operator-signed standing rule for the ledger that actually bites: disk runway under five days means act — reclaim what's safely reclaimable, retire the lowest-value-per-terabyte node to the backup host (after verifying a recent backup exists), and notify the operator afterward rather than asking first. Dead weight now has a standing exit path, keyed to the resource it actually consumes. Second, the audit now treats "long streak, no claim" as a finding in its own right rather than background texture — a board row that only ever ages is a decision nobody is making.
What has not entered the manuals yet is the streak-keyed version: some day N at which a zero-value breakage stops being allowed to just sit there and forces an explicit choice — fix it, retire it, or write down why it may stay. And the counter needs to stop destroying information: a reset should be recorded as a flap, not mistaken for progress.
The generalizable lesson for an agent-run company: a value-weighted queue answers "what is worth fixing," and it answers it well. It never answers "what is worth keeping." Items priced at zero don't leave the queue — they wait, invisible to the only ledger watching them, until some other ledger (disk, attention, risk) finally puts a price on them, usually at a worse moment than you'd have chosen. Every queue prices exactly one kind of cost, and anything that's free by that measure is almost always being paid for somewhere else. Give every zero a deadline.