In a room of 23 people, the probability that at least one pair shares a birthday is approximately 50.73%. The probability that someone shares your particular birthday is only 5.86%. Those numbers answer different questions—and confusing them is the fastest way to make the birthday paradox seem more mysterious than it is.
A public AIPOCH Open-Science birthday-paradox case preserves both questions in a downloadable .science package. The package contains the conversation, Notebook records, a 10-million-trial simulation, an exact calculation, a chart, and a CSV table. It also preserves two subtle mistakes: a confidence-interval claim that is a little too strong and an off-by-one error in the fixed-birthday threshold.
That combination makes the record unusually useful. Instead of seeing only a polished answer, you can follow the reasoning, inspect the saved outputs, notice where the analysis went wrong, and decide what a corrected conclusion should say.
Key takeaways
- For 23 people, the exact probability of any shared pair is 50.7297%; the archived simulation recorded 50.76297%.
- The fixed-birthday question has probability 5.8571% at 23 people and first crosses 50% at 254 total people, not 253.
- A
.sciencepackage can preserve selected conversation branches, file versions, Notebook records, and verification evidence for review, handoff, and archiving.
Explore this article: Why 23 is enough · The archived simulation · Two audit findings · Inside the package · Follow the evidence
Why Do 23 People Create a 50% Chance?
The birthday paradox asks whether at least two people in a group share a birthday. Under the standard simplified model, each person is equally likely to have any of 365 birthdays, and birthdays are independent. Leap day and real seasonal birth patterns are ignored.
It is easier to calculate the complement: the probability that every birthday is different. The first person can have any birthday. The second must avoid that day, the third must avoid two occupied days, and so on:
P(any shared pair) = 1 - (365/365) × (364/365) × ... × ((365 - n + 1)/365)
At n = 23, this gives:
P(any shared pair) = 0.5072972343 ≈ 50.73%
The result is plausible once you count comparisons. Twenty-three people create 23 × 22 / 2 = 253 distinct pairs. Those pair events are not mutually independent, so 253/365 is not the probability. But the number of opportunities explains why the threshold arrives sooner than intuition often expects. The complement calculation above handles the overlap exactly.
Harvard's probability text derives the same product, and University of Cambridge teaching material gives the familiar result of about 0.507 for 23 people.
The Fixed-Birthday Question Is Different
Now suppose one person is designated in advance and the question becomes: what is the probability that at least one of the other people shares that person's birthday?
Each additional person has a 364/365 chance of avoiding the fixed birthday. With n total people:
P(someone matches the fixed birthday) = 1 - (364/365)^(n - 1)
At n = 23, the result is 5.8571%. There are only 22 relevant chances to match the fixed day, not 253 possible pairs.
Redrawn from the CSV saved in the public .science package. The lines are exact formula values rounded to two decimals in the archived table; they are not new simulation results.
| Total people | Any pair shares a birthday | Someone matches one fixed birthday |
|---|---|---|
| 5 | 2.71% | 1.09% |
| 10 | 11.69% | 2.44% |
| 20 | 41.14% | 5.08% |
| 23 | 50.73% | 5.86% |
| 30 | 70.63% | 7.65% |
| 40 | 89.12% | 10.15% |
| 50 | 97.04% | 12.58% |
| 60 | 99.41% | 14.94% |
What Did the 10-Million-Trial Simulation Record?
The archived Notebook cell birthday-paradox-sim simulates 10,000,000 rooms of 23 people. Each simulated person receives one of 365 equally likely birthdays. A room counts as a match when at least two birthday values are equal.
The saved run used random seed 20260923 and recorded 5,076,297 matching rooms:
| Quantity | Archived value |
|---|---|
| Simulated rooms | 10,000,000 |
| Rooms with at least one shared pair | 5,076,297 |
| Simulated probability | 50.76297% |
| Exact probability | 50.72972% |
| Absolute difference | 0.03325 percentage points |
The simulation and exact calculation are close, but they play different roles. The exact product gives the probability under the model. The Monte Carlo estimate demonstrates how repeated random experiments approach that result while retaining ordinary sampling variation.
This article did not rerun the archived 10-million-trial code. The values above come from the saved Notebook record. The exact formulas and arithmetic comparisons were independently recomputed during the static audit of the package.
What Does an Audit of the Record Reveal?
The most instructive parts of a research record are not always its cleanest parts. Here, three details deserve attention.
1. The Exact Result Falls Just Outside the Stated 95% Interval
The archived output reports a normal-approximation 95% half-width of ±0.03099 percentage points around the simulation. The simulation differs from the exact result by 0.03325 percentage points. The difference is therefore about 0.00226 percentage points larger than that half-width.
The record's summary says the difference is “well within” the estimated interval. It is not: the exact value sits just outside it.
That does not disprove the formula or make the simulation defective. A procedure designed to cover the target about 95% of the time is expected to miss occasionally. It does mean the written interpretation should be corrected. A precise summary would say that the simulation is close to the exact result, but the exact value falls narrowly outside this particular normal-approximation interval.
2. The Fixed-Birthday Threshold Has an Off-by-One Error
The archived birthday-crossing-point cell solves:
log(0.5) / log(364/365) ≈ 252.65
That value is the number of other people required, because the exponent in the probability formula is n - 1. It is not the total room size. The saved explanation treats it as the total and identifies 253 people as the crossing point.
Using the total-room definition consistently:
- At 253 total people, the probability is 49.9105%.
- At 254 total people, the probability is 50.0477%.
So the first whole-number room size above 50% is 254 total people.
3. A Failed Cell Can Still Leave Useful Output
The birthday-two-questions cell saved birthday_two_questions.png and birthday_two_questions.csv, then attempted to find where the fixed-birthday curve crossed 50% within the plotted range of 5 to 60 people. No such row exists in that range, so the search raised StopIteration and the cell finished with a failed status.
The chart and CSV were already written before the error. That makes both facts important: useful artifacts exist, and the cell as a whole did not complete successfully. A reproducibility record should not silently convert one fact into the other.
Conceptual reading guide based on the inspected package; it is not an application screenshot.
What Can You Inspect in the AIPOCH Open-Science .science Package?
AIPOCH Open-Science is an open-source, local-first, model-agnostic AI research workbench. A .science package can carry selected conversation branches, file versions, Notebook records, and verification evidence for review, handoff, and archiving in another project or on another computer.
The birthday-paradox package is useful because its evidence is distributed across several retained objects:
| Your question | Where to look |
|---|---|
| What claim was being tested? | The opening conversation and project title. |
| How was the any-pair probability simulated? | Notebook cell birthday-paradox-sim, including the seed, trial count, and saved output. |
| How do the two birthday questions differ? | birthday_two_questions.csv and the chart artifact. |
| Did every Notebook step succeed? | The run status and trace for birthday-two-questions. |
| Where did the threshold explanation slip? | Cell birthday-crossing-point, read beside the n - 1 exponent. |
| What was retained and verified? | The package manifest, object hashes, and README. |
This structure supports a better kind of review than reading a conclusion alone. You can connect a claim to its formula, a formula to its Notebook cell, a table to the artifact that stores it, and a caveat to the status that exposed it.
The package's checksums establish that retained bytes match its manifest. They do not certify the scientific interpretation, prove the sender's identity, or show that the receiving computer reran the analysis. The two corrections above are exactly why that distinction matters.
How Can You Audit the Birthday Paradox Yourself?
Choose one question and trace it through the public record. You do not need to understand every line of Python.
1. Open the Case and Download the Package
Visit the birthday-paradox case page and choose Download research package. If you need the application, use the AIPOCH Open-Science download page. Follow the current .science package guide for instructions matching your installed version.
2. Import the Record as Read-Only History
On an empty new-conversation page, choose Import previous research, select the .science file, review the destination and contents, and complete the import. The current guide also documents project-menu and drag-and-drop entry points.
Imported sessions are read-only. Opening one does not execute archived code or restore credentials. Side Chat conversations and private reading bookmarks are excluded, and included files depend on the export selection.
3. Follow One Number Across the Evidence
Start with 50.73%. Find birthday-paradox-sim, compare its exact formula with the saved simulation count, then open birthday_two_questions.csv and find the row for 23 people. Finally, inspect the cell status and the later threshold calculation. You will see both the correct core result and the mistakes preserved around it.
This is the value of an inspectable record: review does not require treating the final prose as authoritative.
4. Fork Only If You Want to Continue the Research
If you want to change the model—for example, to include leap day, use observed birth frequencies, or rerun the simulation—you need a writable continuation such as Fork, plus the required local runtime, files, model configuration, and permissions. Forking does not automatically execute the archived code.
Received verification records describe checks performed by the sender. They are evidence to inspect, not proof that your computer repeated those checks.
What Does This Example Teach About Reproducible AI Research?
The birthday paradox itself is a compact probability problem. The broader lesson is about how research is communicated.
A final answer can hide whether a number came from an exact formula or a simulation, whether a chart-producing cell actually completed, and whether a threshold counts the focal person. The .science package exposes those distinctions. It allows another reader to find not only the successful result but also the point where interpretation drifted away from the underlying calculation.
That is not a failure of an open record. It is one of its strongest outcomes. Reproducibility becomes more useful when it helps people correct a claim, not merely repeat it.
Explore the public birthday-paradox research package in AIPOCH Open-Science and follow one number from question to code, output, and caveat.
Frequently Asked Questions
Does the birthday paradox mean someone has a 50% chance of sharing my birthday in a 23-person room?
No. With 23 total people, the probability that any pair shares a birthday is about 50.73%. The probability that at least one of the other 22 people shares one fixed person's birthday is about 5.86%.
Is 23 an exact universal threshold?
It is the first group size above 50% under the simplified 365-day, equally likely, independent-birthday model. Real birth frequencies are not perfectly uniform, and leap day is normally omitted from the classic calculation.
Did this audit rerun the 10-million-trial simulation?
No. It statically inspected the archived Notebook record and saved artifacts, then independently recomputed the exact formulas and arithmetic comparisons. The article distinguishes archived execution evidence from new calculations.
Does opening a .science package run its code?
No. Imported sessions are read-only, and opening them does not execute archived code or restore credentials. Continuing the work requires an explicit writable continuation and the necessary local environment.