Our price freeze caught our own picker. Here's the full audit.

On 8 August we added a tripwire to the public ledger: an audit table that records the old row any time a published pick is changed or deleted. We built it to prove to you that picks can't be quietly edited.

Three days later it went off. The thing editing our picks was us.

What was happening

Our daily card is picked by a cron job that runs several times each morning as new races get priced up. The bug: on every run, the picker deleted and re-picked every race that hadn't yet been run — and each re-pick recorded the advised price available at that moment, not the price we first published.

"Logged before the off" was technically true. But a pick you publish at 09:05 and silently re-publish at 12:38 with a different price is not a frozen record. It's a moving target that happens to stop when the race starts. For three days the audit table recorded exactly that, with timestamps:

Tuesday 11 August — all four picks, Lingfield:

Saturday 8 August: Sunlit Sea (Lingfield 6:10) was published at 3.25, re-published at 3.35, again at 3.40, and finally — by coincidence — at 3.25 again.

Crazy Plan is the ugly one: the horse drifted through the morning, and our "published" price quietly followed it from 6.60 to 11.00 — a 67% inflation on the number we'd have settled a win against.

What it did and didn't corrupt

Checked against the audit table, line by line:

• No settled pick in the audited window carries a mutated price. Sunlit Sea's final publication happened to match its first (3.25), and it lost — a level-stakes loss is −1 point at any price, so the ledger's P/L was right either way.
• Tuesday's four picks were restored to their first-published prices at 13:39, 51 minutes before the first off — taken straight from the audit table's preserved old rows (6.60, 6.60, 7.80, 10.00). The restoration is itself recorded in the same audit table, because the trigger doesn't have a "trust me" exemption for us.
• What was corrupted was what you saw pre-off: a price labelled as published that was actually being refreshed. That's the promise broken, even on days when the arithmetic came out unharmed.

The part we can't reconstruct

The buggy delete-and-re-pick behaviour shipped on 20 May. The freeze audit has only existed since 8 August. Between those dates the ledger recorded 213 picks across 50 race days, and for every one of them the stored advised price is the last publication of the day — not necessarily the first.

Up to 118 of those rows were inserted after the day's first picking run. Some of those are innocent (races legitimately added once bookmakers priced them up); some were silent re-publishes. The database cannot tell them apart, and neither can we. The direction of the error is mixed — drifters got recorded at bigger prices, steamers at shorter ones — so we can't even tell you which way it leaned.

That uncertainty is now permanent, and it's the strongest argument for the freeze existing at all.

The fix

As of 11 August (commit 7ee98c0 in our codebase):

1. The picker is append-only. A race's first published pick is final at the database layer — later runs can add picks for newly priced races, but an existing row is never touched, even when the model would now choose differently.
2. Any change or deletion that does happen lands in a public audit table with the old row preserved. The deletion count is shown on the track record page — it stands at 15, all from this episode, and should never grow again.

Why we're telling you

The freeze existed for three days before it caught us. That's not embarrassing — that's the system doing precisely what it was built for, against precisely the party you'd least expect to be policed: the site itself.

We publish every losing week. Publishing our own bugs is the same discipline. If we'd quietly fixed this one, nothing else on this site would deserve your trust.

Every claim above is verifiable in the audit table (shadow_pick_revisions, public read access) — timestamps are UK time.