lotto ev toolkit / architecture
The repository is called a prediction system. It is not one, and its own backtest is what proves it. What it actually automates is the only part of a lottery a player controls: deciding when a ticket is worth buying, and keeping an honest ledger of what happened when it was.
Draws are independent and uniformly random, so no method here beats random picks — the walk-forward backtest says so, and the dashboard prints it. Expected value only turns positive on rare roll-downs, and even then on fewer than half of them.
Scheduled workflow
Wednesday and Saturday, after the evening draw has settled
21:45 UTC, with a retry at 06:00 the next morning
Official results feed
Draw numbers and the full prize breakdown per tier
Sales figures pulled too — they drive the whole model
Recalibration
Fixed prize tiers re-derived from the new draw, popularity weights refreshed
Roll-down uplift priced separately so it cannot skew the median
The repository is the database
The workflow commits the updated history back to the repo
No database to run, back up or pay for — git is the ledger
Collection watchdog
A separate workflow that checks the collector actually produced a draw
Missing data is silent — so absence is what gets checked
Two draws a week is not a workload. Anything more than a scheduled job and a versioned file would be infrastructure bought for its own sake.
Is tonight worth £2?
The only question the toolkit tries to answer
Sales close 19:30 UK time — the clock, not the calendar
Expected value
Exact tier probabilities, current jackpot, both rounds, expected co-winners
Jackpot odds 1 in 45,057,474 — asserted in tests, not assumed
Stress the fragile input
Ticket sales dominate a roll-down, so the verdict is reported across the sales range
Clears only on the central estimate? Not an opportunity
Pick unpopular lines
Lower tiers are fixed, but the jackpot is shared — so avoid dates and patterns
Weights calibrated on 1,126 draws of match-3 winner counts
Email, roughly nine times a year
Draw, jackpot, EV, break-even, the lines, and the command to log them
Lines seeded from the draw date, so the retry proposes the same portfolio
Median expected value across them is −£0.14. Must-Be-Won is a necessary condition for a good draw, not a sufficient one — which is why the advisor prices each one rather than trusting the calendar.
Walk-forward backtest
Each method scored out of sample against the no-skill baseline
Monte-Carlo p-values and bootstrap intervals — not eyeballed
The result it publishes
Nothing beats random picks, and the dashboard says so on its face
A negative finding, kept in the product
ROI ledger
Every line actually bought is recorded, then settled against the real result
The dashboard reports the outcome in pounds, not in accuracy
CI on every push
The probability tables and the draw-date logic are pinned by tests
A test that encoded a bug was deleted, not worked around
The correction is in the README
An earlier headline claimed 96% of roll-downs were profitable
Re-priced on measured sales it became 27 of 65 — and stayed published
A system that cannot tell you it failed is not a measurement system. This one reports a negative result on its own dashboard, which is the only reason its positive ones are worth reading.