The lottery experiment
Can we predict the lottery? An experiment that tests the methods people believe in. None of them has beaten luck.
The lottery experiment on 3 October 2026. The game selector is blurred. The page states that draws cannot be predicted and that expected winnings are negative.
What it is
Can we predict the lottery? This app was built to answer that honestly, and the answer so far is no.
It collects years of draws from three Norwegian lottery games, with prize tables, from the operator’s open results API. A dashboard then does two things. First, it tests the methods people actually use to pick numbers, such as hot numbers, cold numbers and birthdays, by letting each one pick every week and comparing it with a random control. None has done better than chance. Second, it studies something that is real: players do not choose numbers at random. Rows full of birthdays are shared by more winners, so the same win pays less.
That second effect cannot make anyone win more often. The app says so in its suggestions view, together with the fact that the expected return on a ticket is negative. It does not encourage play.
How it works
Three containers: a database, the dashboard, and a scheduled job that runs every morning. The job fetches new draws, scores last week’s predictions, refits the model and makes new ones. Every prediction is stored before the draw, so it can be checked afterwards.
The statistics are classical: chi-square tests, a Poisson model of how many winners each prize tier gets, a forecast of how many tickets will be sold, and corrections for testing many things at once. A negative result is reported together with the smallest effect the test could have seen. There is no language model in the app. We built it from a spec with 28 definition-of-done checks.
What we expected, and what happened
Read it like a code review. Each removed line is something we expected, from a plan, a spec, a README or a code comment. The added line under it is what the history shows actually happened.
Expected: The spec ruled out predicting drawn numbers. When Henning asked for it anyway on 5 July, it was built as a test rather than a prediction: methods people use, such as hot and cold numbers, each pick numbers every week and are scored against a random control.
Happened: After 22 draws across the three games, none of the four original methods differs from luck (p between 0.15 and 0.82). More methods have been added since, and the app states the most any of them could still beat luck by.
Expected: The real hypothesis was that some numbers are chosen more often by players, so the model should predict how many winners each prize tier gets, and beat a naive baseline or count as failed. The first evaluation on 4 July showed it twelve times better than the baseline.
Happened: The baseline was wrong: it averaged across prize tiers with very different sizes. Corrected on 15 July, the lead shrank to a modest margin. By 5 August the model lost to the baseline in the main game, and the dashboard says so. The other two games still lead.
Expected: The weekly cycle stored its predictions, and its tests passed.
Happened: Every write in production was rolled back when the connection closed. The tests did not see it because they read inside their own transaction. Found on the first live run and fixed the same day.
Expected: A stronger hunt for bias in the draws (pairs of numbers, drift over time, links between draws) might find what the simple frequency test misses.
Happened: Over 781 draws, a test of whether the first half's oddities repeat in the second half gave p = 0.98. No single number and no link between draws stood out. One pair of numbers did, and it is treated as a hypothesis to be tested on new draws, not as a finding.
Page history
- First version of this page.
- On 3 October 2026 we checked the app's repository and found no new commits since the last update, so the page content is unchanged.