How the ratings work
The published model
Elo updates a team’s rating after a completed match, using the result and the opponent’s rating. Test, ODI, and T20I matches form separate rating pools.
| Setting | Value |
|---|---|
| Initial rating | 1000 |
| K | 100 |
| Expected score | normal CDF |
| Ties | 0.5 each, including regulation ties resolved by a tiebreaker |
| No-result matches | no update |
| Update order | end_date, start_date, match_id |
Draws and ties count as half-results. A regulation tie resolved by a tiebreaker is treated as a tie when the source records it that way. Abandoned, cancelled, and no-result matches do not update either team’s rating.
The implementation is EloRating::e.single, version 0.46.18, from the R package EloRating. The complete specification is included in the publication metadata.
Dates and history
Matches enter on their completion date. Same-day results use the deterministic ordering shown above. Monthly downloads contain calendar-month-end snapshots; the charts show end-of-day match updates, including the latest partial month. Ratings carry forward between results. The charts do not smooth the estimates.
Histories are reconstructed from the current saved source version. They do not prove what could have been known from the source at an earlier date. Git history records successive actual publications.
Which teams are ranked?
Teams are active if they have played a rated match within 730 days. Teams with fewer than 10 rated matches are provisional. Equal ratings share a competition rank. Inactive teams remain in the CSV without a current rank. These are our display rules, independent of ICC rules.
What the ratings leave out
This baseline has no venue or margin adjustment, inactivity decay, player-lineup effects, or uncertainty intervals. A fixed K controls responsiveness to results; the trajectory is an estimate under those choices, not directly observed ability. Sparse schedules and weak connections between opponent groups can limit comparisons.
We plan to compare richer models using chronological forecast evaluation. The research agenda describes these choices, including the distinction between live predictions and retrospective historical estimates.
Correctness and reproducibility
Source responses are saved and checked before modeling. Published files are verified against their recorded hashes before the website renders. The site reads saved results and does not refit the model.
The correctness audit documents the old outcome and timing errors, the corrections, and the numerical validation. Code and tests are available in the repository.