THE ALERT, NOT THE APP
A real-time routing advisor for one commute — Cambridge ↔ London — that stays silent until a decision is forced, then says exactly what to do while there’s still time to do it.
THE CONTEXT
Three ways home from London, and they are not alike. The fast train from King’s Cross does it in an hour. Thameslink from St Pancras is the quick sidestep when only your train is broken. The Greater Anglia divert from Tottenham Hale is the escape route when the whole main line is down — and it’s only reachable by staying on the Victoria line, so the decision has to be made underground.
Every commuting evening ends with the same bet, placed with imperfect information, sixty feet below street level. Get it right and it’s an hour door to door. Get it wrong — divert when the line was about to recover, or hold when it wasn’t — and the evening is forty minutes to an hour longer. I’d made both mistakes often enough to see that the failure was never knowledge. It was timing: the right information exists, it just doesn’t reach you at the one moment you can still act on it.
THE PROBLEM
The data was never the hard part. The system has exactly two hard jobs: know the phase — at the desk, on the Underground, surfaced, on the train — because an alert fired at the wrong phase is noise; and encode the reroute judgement precisely enough that every alert is act-on-it, not think-about-it.
- P.1The verdict must land before the Victoria line reaches King’s Cross — after that, the divert is gone.→
- P.2Sources disagree: the fastest feed can lag a short-notice cancellation by exactly the minutes that matter.→
- P.3Incident feeds over-match: a fault forty miles off-route once flagged the divert as SUSPENDED.→
- P.4A false divert costs forty minutes and erodes trust. A missed systemic failure costs more than an hour.→
THE APPROACH
Spec first — and the spec is the product. A frozen decision model, an explicit bias setting (“hold, unless the trend overrides”), and three seed fixtures, each one a real evening that had gone wrong. The decision engine is a pure function — no network, no clock, no I/O — built test-first against those fixtures before any plumbing existed.
The loop this site talks about isn’t theoretical here. When production produced a new failure — a cancellation one feed saw minutes before the other; a points failure miles off-route wrongly suspending the divert — the investigation ran directly against the live APIs that same evening, with AI in the code. Each failure was a replayable fixture before bed: discovery, fix and regression test in one sitting, with nothing in between.
Every failure becomes a fixture the same evening. Each mistake is only available once.
The counterfactual team runs this as a quarter of roadmap: a data-ingestion sprint, an alerting epic, a backlog. Built solo with AI in the loop, the distance from “spec frozen” to “engine passes every fixture” was measured in evenings — and the distance from each production surprise to its shipped fix has been measured in hours ever since.
THE BUILD
One Python process on a tiny cloud box. A pure decide(phase, snapshot) engine wrapped in tiered pollers over four live feeds — running data, a second independent cancellation source, the national incident feed, and Underground line status. iOS geofences arm it as I leave the office; Telegram carries the verdict; a ledger detects every claimable delay and pre-fills the compensation claim.
- D/01THE ENGINE IS PURE — NO NETWORK, NO CLOCK. EVERY REAL FAILURE BECOMES A REPLAYABLE FIXTURE.—
- D/02TWO INDEPENDENT FEEDS ON CANCELLATIONS — EITHER SOURCE CANCELS; DISAGREEMENT IS SURFACED, NOT HIDDEN.—
- D/03BIAS TO HOLD, TREND OVERRIDES — A WORSENING PATTERN CAN ESCALATE BEFORE AN INCIDENT EVEN POSTS.—
- D/04AI SECOND OPINION ON DEMAND, NOT IN THE LOOP — ONE CLAUDE CALL ARGUES WITH THE ENGINE'S VERDICT; THE ENGINE NEVER WAITS ON A MODEL.—
THE OUTCOME
In production on my own commute since June 2026. It stays silent for days at a time — silence is the product working — then lands one push that changes which platform I walk to. Cancellations surface within a minute from whichever feed sees them first, and every claimable delay is logged with the evidence already attached.
One user, one route, deliberately unscalable — and that’s the point. This is the homepage’s argument at its smallest possible scale: rebuild the loop, and one person, in the evenings, ships and operates a production system that used to take a team. The interesting question isn’t how to build a train tool. It’s what your organisation would ship if its loop ran this fast.