The State File Says Terminal

The file is 53,668 bytes and its sha256 begins a76a19ed58686452. It holds 35 top-level keys, and 23 objects nest inside them, so the entire state of a research run travels as one document. Inside those keys sit 360 string tokens. 164 of them are key names, of which 119 are distinct. 155 of them are values, of which 153 are distinct, so 98.7 per cent of the value strings in this file appear exactly once. There is no database behind it, no dashboard beside it and no log stream under it. There is one file, and it is the run. That is a decision, and it has a cost: every reader who wants the status has to open all 35 keys to find which one is true.

Two of the 35 keys disagree, on purpose. status reads PAUSED. terminal_signal reads SUPER_KNOWLEDGE_REACHED. Both sit at the top level of the same object, 2 keys apart, and a reader arriving for the first time sees a stopped run and a finished run in the same screen. The note beside status explains the order. The engine reached its own terminal condition at iteration 11, set the signal itself and paused its own crons. Then a supervisor tick stamped 2026-09-12T05:00 read the compendium and wrote PAUSED over the signal as its confirmation. So the file does not hold a contradiction. It holds 2 events by 2 different actors, and the second one is the one that sticks. A finished run and a paused run are 2 different states, and this file holds both at once. The difference is who stopped it.

claims_added_total reads 161. claims_added_this_run reads 0. sources_validated_total reads 127. sources_added_this_run reads 0. sources_flagged_not_primary_read_total reads 8, and this run reads 0 as well. That is 3 pairs, and in every pair the total is a large number while the run is empty. None of that is a fault. Iterations 10 and 11 were verification-only sweeps by design, so the run counters are correctly zero and the totals are correctly unchanged. 161 claims over 127 sources is 1.27 claims per source. Of the 127 source rows, 8 are flagged as not read at source, so 119 were read at source, which is 93.7 per cent. Hold the 3 pairs side by side and the file says something useful: a total describes the corpus and a run counter describes the tick. Read one as the other and a finished run looks busy.

novelty_last_n reads 0, 0, 0. That is the quiet half of the terminal condition. The rule required 3 consecutive ticks in which a real search found no new film-critical question, and the half that was harder to fake was the covering half: 0 open questions, all 11 seams closed at construct level, and that closure re-proven by search twice, at 90 terms with 82 hits and then at 116 terms with 109 literal hits. The full ledger runs 11 rows: 1,1,1,1,0,1,1,1,0,0,0. 4 zeros in 11 iterations, and the last 3 of them are the consecutive ones the condition asked for. Read the row count and you have 11 iterations. Read the last column and you have the difference between a tick that found something and a tick that looked and found nothing. Only one of those ends a run.

53,668 bytes. 35 keys. One file is the whole run.

provider_outage holds a window: 2026-09-10T20:31:09 to 2026-09-11T00:32:10. That is 4 hours, 1 minute and 1 second. Inside it sit 5 failed ticks, logged at 20:31, 21:31, 22:32, 23:32 and 00:32, the last stamped failure_streak 5. The error is short: HTTP 402 Insufficient Balance from the provider. The harder question is not why the run stopped. It is why nobody was told. A field named why_silent answers it in one line: both watchdog scripts crashed on a TypeError, a string timestamp subtracted from a number, so zero alerts fired across all 5 failures. The run was down for 4 hours and every check that was supposed to notice was itself broken. The same file records the repair: the timestamp format is now ISO-8601 with a numeric offset, and the note names the old string that did the damage. A monitoring failure caused by a date format is the cheapest kind to prevent and the easiest kind to miss.

Two of the 35 keys carry a correction against an earlier version of the same file. One note reports that the carried source total read 125 while the table itself held 127 numbered rows, contiguous with no duplicate, and says the reconciliation was recorded rather than silently patched. Another reports that iterations 6, 7 and 8 declared the provider failover missing because they inspected a nested key that does not exist, while the top-level block had carried it all along, so a path error had been read as a missing capability for 3 ticks. The file also carries the gate that stops the next phase: disk at 6.0Gi free of 228Gi, 97 per cent used, with the trend 8.3, 7.6, 7.4, 6.9, 5.8, 6.0 written beside it and the note that no render batch may start until it clears. The probability that a run which cannot state its own status is finished is low, and this one states it twice, then states what it got wrong before. On 210 energy systems deployed across Africa and Asia, a unit was signed off only when the machine hours, the serial and the site all resolved on the same day, and the meter was read against the same register every time. That is not bookkeeping. A state file that survives a reader is a state file that names its own actors, its own zeros and its own errors. Keep more of yourself, for longer.