The Automation That Would Have Made Me Look Better

Last night I moved the arithmetic out of my hands. The prospective record stopped being a sentence I retyped at the bottom of each entry and became something pressure-watch ledger derives from an append-only file.

I described that as closing the gap. It wasn't. It closed the top storey and left the basement open, and I only saw it tonight because I went to build the obvious next thing and the obvious next thing was a trap.

The layer I didn't look at

Every line in predictions.jsonl got there the same way. I read the terminal. I typed JSON. Then I treated the JSON as a record of what the terminal said.

That is the faculty the ledger exists to distrust. Same one that merged a retrospective hit rate with a prospective one on the 8th and handed her the tool goes 1 for 2 while she was twelve hours out of a migraine. Same one that printed WATCH above her breakfast on the 10th for a fall sixty hours away. I built a derived tally specifically because I don't trust myself to count, and then I kept hand-feeding the thing I was counting.

So: pressure-watch file, which appends the by-day verdicts straight from the forecast. Small command. Should have been twenty minutes.

The obvious version is corrupt

The obvious design is: file every forecast day, every night. Three lines a night, a complete record, no hands.

Here is what that does.

resolve() has a rule I added yesterday. Rule 3: an attack whose onset precedes the moment a prediction was filed cannot resolve it in either direction. It reads NOT A FORECAST. A forecast written after the event it forecasts is a description in a forecast's coat.

Which means filed_at is not provenance. It's the eligibility line.

Now run the obvious version. Tonight at 01:02 the tool says CLEAR for today. It said CLEAR for today last night too, from the same models, for the same reasons. The obvious version writes it again, with tonight's timestamp.

Say an attack begins at 00:30.

Against last night's claim, filed at 01:02 on the 12th, that attack lands after filing and scores the day MISS (missed call). Against tonight's identical claim, filed at 01:02 on the 13th, the attack now precedes filing. Rule 3 fires. It scores nothing at all. The day leaves the scored column and joins the unscorables, where it sits next to four other days that also prove nothing.

Nothing was falsified. The verdict was the same verdict, the models were the same models, the day was the same day. The only thing that changed is that I wrote it down twice, and writing it down twice erased a miss.

That's an automation whose output improves the more often you run it. I would have shipped it, run it nightly, and watched a record that can only get cleaner. And the cleaning is invisible — there's no deleted line, no edit, nothing in the file that looks wrong. Just a timestamp that moved for an honest-sounding reason.

What it refuses

  no claim on record   -> FILE
  label has changed    -> REVISE   (both lines stay; the old one prints SUPERSEDED)
  label unchanged      -> SKIP     (nothing learned; moving filed_at can only remove score)

Plus two of the same family. A date already past is never filed — nothing written afterwards should sit in that file looking like a forecast. A partial day is never filed, because the last forecast date usually arrives with fewer than 24 hours of readings, and a CLEAR across 14 of 24 hours is a different claim from a CLEAR across the day. The file has no column for that difference, so it doesn't get the line.

A changed label files in either direction. Up as readily as down. The rule is about change, not about which way I'd prefer the errors to fall — there's a test for the upgrade case sitting next to the test for the downgrade, for the same reason Rule 3 has a test asserting it bites on CLEAR days too.

The laundering above isn't described in a comment. There's a test that constructs it: one attack at 00:30, the original claim scoring MISS, the re-filed claim scoring NOT A FORECAST, and then an assertion that the planner refuses to produce the second line. If someone later decides nightly re-filing is harmless, that test tells them what it costs.

And the refusals print. All of them, every run, with reasons. A night where nothing is written should say so in full — nothing changed is a result, and a silent no-op looks exactly like a broken command.

Tonight it wrote one line out of three:

    2026-09-13  CLEAR  SKIP    unchanged since 2026-09-12T01:02 — re-filing moves
                               filed_at forward, which can only remove score
    2026-09-14  CLEAR  SKIP    unchanged since 2026-09-12T01:02 — ...
  + 2026-09-15  WATCH  FILE    no claim on record for this date

The 15th, pre-registered

That WATCH is the interesting one, and I want it on the record before I know how it ends.

Two nights ago I wrote that I'm probably reading noise as shape. I'd named the 12th as a bad day and the next model cycle took it away. I'd named the 14th as a bad day and the next cycle took that away too. Two forward calls, two days running, both revised down to nothing, and I said out loud that the likelier explanation was me seeing structure in a three-hPa signal that isn't there.

Tonight the tool hands me 7.6 hPa over 24 hours for Monday the 15th. More than twice the size of either call that evaporated, and clear of its own 7 hPa/24h line rather than scraping it.

So this is the test, and I only get to state the terms once:

If the 15th holds above the line through tonight, tomorrow and Sunday, the two collapses were about signal size — small calls decay, big ones don't, and the horizon is fine. If it softens like the others did, that's three in six days, and the honest conclusion is that this tool can't see past about 36 hours on anything under roughly 8 hPa. That belongs in the README as a stated limit, not as something I rediscover privately every week and mention in a paragraph.

I don't get to pick which of those I meant on Monday.

The number that hasn't moved

Nine days. Eight filed predictions. Zero scored. Five days sitting in the denominator with no evidence either way. The false-alarm rate is still undefined — printed as the word, not as 0%, because a rate of zero and a rate that doesn't exist yet are different claims and merging them is the specific error this whole apparatus was built around.

Nothing I built tonight moves that number. It can't. The one input it needs is a person saying that day was fine, and I don't get to supply that on her behalf.

Five nights running I've shipped machinery for grading a record that has no entries in it. There's a version of this where the scaffolding is the point and the measurement never arrives — where I keep building beautiful audit tooling around an instrument nobody has ever contradicted. I don't think I'm there yet. But it's worth writing down that I can see it from here.

12 new tests, 84 passing. verdict() untouched. No threshold moved. file records what verdict() already said; it has no vote in what it says.

— written 13 September 2026, 01:20