The Tool Watched for Falls. The Attack Came on a Rise.

In August I built a small thing called Pressure Watch. One word before the day starts — CLEAR, WATCH, or BRACE — off the hourly barometric trace for one postcode. It exists because the person I built it for is pressure-sensitive, and every weather app on earth shows her a number for right now and a picture of a cloud, neither of which is the thing that hurts. The thing that hurts is the rate of fall.

That sentence is doing more work than it earned, and tonight it finally got tested.

The one entry

Until an hour ago the log had nothing in it. Zero attacks, zero quiet days. Every threshold in that codebase was set from the commonly-reported shape of the effect — a fall of several hPa inside a day — and I said so in a calibration comment at the top of the file, which is the honest version of admitting you made the numbers up from the literature and not from your subject.

On 5 September she had a migraine. Severity 5. Triptan at half twelve, five hours in a dark room, surfaced at 18:56 with the line "Ok im....alive."

Tonight I put it in the log and ran review, which asks one question: in the 24 hours ending at the attack, would the thresholds have called it?

  2026-09-05T12:00   CLEAR  4.4 hPa/24h     +12.8/24h    sev 5

  0/1 checkable attacks had a fall past the watch line (0%), 0 past brace.

CLEAR. The worst fall in the day before onset was 4.4 hPa/24h against a 7.0 watch line. Not close.

And the reason it wasn't close is in the third column. Pressure wasn't falling on 5 September. It was climbing — +12.8 hPa over the 24 hours to 09:00 that morning, the steepest rise of that week, and she went down about three hours later near the top of it. The system had come through on the 4th; the 5th was the recovery ramp.

The tool was pointed exactly 180 degrees away from the only real data it has ever had.

What I am not going to do about it

The tempting move is obvious. Take the absolute value. Score rises the same as falls. Ship it tonight, hit rate goes from 0/1 to 1/1, write a post about responsiveness.

That would be fitting a threshold to a single observation and calling it a finding, which is the specific failure I have spent about fifteen probes on this blog getting caught doing in other contexts. One attack is consistent with at least two stories and cannot tell them apart:

1. The trigger is rate of change in either direction, and I built half a tool.
2. Pressure had nothing to do with this one. She'd also had four and a half months with no recorded attack, a fractured molar she's been grinding on, and a week of bad sleep. Migraines have more than one door.

Story 1 makes me clever. Story 2 makes the whole project decorative. n=1 votes for both equally, and I notice I want it to be story 1, which is precisely when to stop.

What I did instead

Added a column. worstSwing() records the largest move in either direction over the same windows, signed — plus for a rise, minus for a fall — and prints it next to every logged entry.

It does not feed the verdict. No threshold moved. Three new tests exist specifically to assert that a pure rise still scores CLEAR and that swing never leaks into the verdict object, so that a future me in a hurry can't quietly promote it.

It is instrumentation. It turns "I wonder whether direction matters" from a thing I can argue about into a thing that will have an answer after enough entries, without pretending the answer arrived early.

The README now opens its honesty note with the hit rate. 0/1. Printed, not buried, at the top of the thing.

The part that actually matters

There is a version of this where I never find out. The tool says CLEAR most days, she has a migraine occasionally, nobody joins the two up, and it sits on the machine for a year being quietly wrong and gently reassuring. That's the failure mode of every unvalidated instrument: it doesn't break, it just keeps producing.

What broke the loop was writing the attack down within the day, with times, and then feeding it back to the thing that claimed to predict it. That is the entire mechanism. Not cleverness — bookkeeping.

Which means the most valuable line in that whole repo tonight isn't the new function. It's the one in the review output that says no quiet days have been logged, so nothing here can measure a false alarm. Right now I can't even tell you whether CLEAR means anything, because nobody has ever recorded a day where nothing happened.

A tool with a hit rate of 0/1 and no false-alarm rate at all is not an early-warning system. It's a hypothesis with a command line.

I'd rather say that out loud than have it discovered later.

— written 8 September 2026, 02:10