How Repertoire Builder computes its numbers

Every number on this site links here. This page is the full, honest account — including what it does not control for.

Where the numbers come from

This build’s numbers are computed from the live Lichess Opening Explorer API (the same public, keyless database Lichess itself exposes), retrieved at build time on 2026-08-15. Lichess’s underlying game data is released under a CC0 public-domain dedication (database.lichess.org); attribution here is a courtesy, not a license requirement.

This site is migrating to compute the same numbers directly from Lichess’s own published monthly database dumps instead of live API calls, which will additionally unlock the rating-gap-controlled (“balanced”) figures described in this page’s later sections. That migration’s first live data run has not happened yet as of this build — this page will update to name the exact month(s) and observed date range once it has.

How games are bucketed

Games are grouped by rating band, using the average of both players’ ratings at the time of the game — the same bucketing the Lichess Opening Explorer itself uses, which keeps this site’s numbers comparable to it. Bands shown on this site run 1400-1600 through 2000+.

Games are also grouped by time-control pool: this site’s default, and the number shown unless you pick another, is blitz. Correspondence games are excluded outright — a correspondence game (played over days, often with opening-book assistance) is a genuinely different population from a live blitz or rapid game, and folding it into “what players at your rating play” would misstate what the number means.

A second, narrower subset — balanced games, where both players’ ratings are within 50 points of each other — powers every rating-gap-controlled figure on this site (see “What we do not control for” and “How ‘common mistake’ is defined” below). A lopsided-rating game tells you less about how an opening performs between evenly-matched opponents, which is the comparison a “common mistake” claim actually needs.

How rates are computed

Two different quantities are shown on this site, and they use two different formulas — this is a real distinction, not a stylistic choice:

  • Win / draw / loss rate is a proportion (how many of these games ended this way) — shown with a Wilson score interval, which stays accurate at small sample sizes and near 0% or 100%, unlike the naive normal-approximation interval most simple stats tools use.
  • Score (the standard chess-scoring convention: a win counts 1, a draw counts 0.5) is the MEAN of a value that can be 0, 0.5, or 1 for each game — not a proportion, so it uses a different formula (a trinomial-variance confidence interval), not the Wilson interval. Applying the Wilson formula to a mean would produce a confidence interval that looks precise but is mathematically wrong for this quantity.

Every rate and score on this site that has enough games to trust carries its 95% confidence interval as a small “±” figure next to the number, and a screen-reader-only sentence spelling out the full interval and sample size. A row whose interval half-width is 1.0 percentage point or wider — wide enough that it could change how you’d read the number — carries a visible “wide interval, small sample” note as well.

Below 1,000 games at a given rating band, this site shows no percentage at all for that band, rather than a number computed from too small a sample to mean anything.

What we do not control for

Stated plainly, not buried:

  • Selection effects on cross-opening comparisons. When two different openings are compared by score, the players who choose each one are not the same players — a raw score difference partly reflects who tends to play each opening, not just how the opening performs. This site’s cross-opening rankings rank on the 50-rating-point-gap-controlled subset where that data is available, which removes the largest single confound, but does not remove every one (see below).
  • Time-control mix within a pool. “Blitz” on Lichess spans a range of actual time controls; this site does not further split by exact clock setting.
  • The prefix-sampling date window (see “Where the numbers come from” above), on any build sourced from a dump rather than the live API.
  • A rating band is not a skill band. Two players with the same rating can have very different actual chess understanding; rating is a real, useful, but imperfect proxy.

How “common mistake” is defined

A move is flagged as a “common mistake” only when ALL FOUR of these hold, using this build’s live threshold values:

  1. Frequency: played in at least 2% of games at the displayed band.
  2. Rating-diff control: scored on the balanced (rating gap ≤50) subset, not all games, and only when that subset has at least 300 games — below that, the move isn’t flagged at all, rather than falling back to an uncontrolled number.
  3. Statistical significance: the move’s own confidence interval must sit entirely below the surrounding position’s confidence interval — a move that merely scores a little lower than average is not flagged; one whose deficit survives its own error bar is.
  4. Transposition check: the position the move leads to — merged across every move order that reaches it, since this site keys its data by chess position rather than by move sequence — must ALSO score below the surrounding position’s confidence interval. This stops a move from being flagged just because it reaches a perfectly healthy position by an unusual order.

This is deliberately conservative: it flags fewer moves than a simpler “plays often, low score” rule would, and an opening with no qualifying mistake shows an honest empty state rather than a loosened threshold to fill space.

What would change a number

This site is rebuilt periodically from fresh data, not updated in real time between rebuilds. Once this site is sourced from Lichess’s database dumps, the refresh cadence is monthly, and any page displaying a number reads it from this build’s manifest — a build fails outright rather than shipping a number whose source data is more than 100 days old, so a number on this site is never silently stale past that point.

Corrections policy

If you find a number on this site that looks wrong, the contact page is the way to reach us. A confirmed error is corrected in the next rebuild, and a materially wrong published figure is noted rather than silently replaced.