rolling chess engine rating lists
Rolling ratings update as new games enter a rating database, whereas frozen snapshots preserve the state of a rating table at a defined time. Both forms of publication are necessary, but they answer different questions. A rolling table describes the best currently available estimate under an active calculation policy. A frozen snapshot records what a publication stated at a particular date, with a particular game population, identity policy, software configuration and statistical model.
This distinction is fundamental for the interpretation of chess engine rating lists. A live Elo value may change after a newly completed game, the correction of a malformed PGN record, the addition of a previously disconnected engine pool, a change in the rating anchor, or a decision to merge several engine versions under one identity. Historical recalculation may therefore alter the displayed rating of an engine even when none of that engine’s own game results has changed.
A scientifically responsible publication system should preserve both contemporaneous editions and later recalculations. It should identify calculation cutoffs, exact engine identities, game counts, rating-tool versions, command-line settings, database hashes, uncertainty measures and correction status. It should also distinguish between “the rating published at the time” and “the rating calculated today from historical evidence.”
This article develops a practical framework for rolling publication, frozen snapshots, retrospective recalculation and archival correction. It draws on public computer-chess rating practices, statistical work on dynamic paired comparisons and research-data guidance concerning persistent identification, versioning and citation.
Direct answer
Rolling ratings update as new games arrive, while frozen snapshots preserve what the table said at a defined date. A serious chess engine rating publication needs both because current usefulness and historical citability are different requirements.
A rolling list answers: What does the accumulated evidence indicate now?
A frozen snapshot answers: What did the publication report at a specified time, under a specified methodology?
A historical recalculation answers a third question: What estimates result when an old game population is processed again using corrected data, revised identities or a different calculation policy?
These three objects should not be presented as though they were interchangeable.
1. A chess engine rating is a model output, not a permanent property
Readers often encounter an engine rating as a compact row containing a rank, engine name, Elo value, error margin and number of games. The presentation can make the rating appear to be an intrinsic and permanent property of the binary. It is not.
A published rating is an estimate derived from a defined set of results. Its meaning depends on at least six components:
- the game population;
- the rating model;
- the engine-identity policy;
- the scale or anchoring convention;
- the resource and tournament conditions;
- the calculation cutoff.
A useful formal representation is:
[<br>\widehat{\mathbf{r}}_t =<br>F(D_t, M, I, A, C),<br>]where:
- (D_t) is the game database available at cutoff time (t);
- (M) is the rating model and software implementation;
- (I) is the identity mapping applied to engine names and versions;
- (A) is the anchoring or normalization rule;
- (C) represents other calculation settings;
- (\widehat{\mathbf{r}}_t) is the resulting vector of rating estimates.
The notation makes an important fact visible: the rating is conditional. Change the database, model, identity mapping, scale or settings, and the output can change.
BayesElo is officially described as software that reads PGN game records and estimates Elo ratings from them. Ordo likewise calculates ratings from a PGN result population, but uses a different model and determines the ratings by considering the results together. Ordo also exposes normalization and anchoring options, while BayesElo provides commands capable of changing the displayed rating offset. These capabilities demonstrate why an absolute number cannot be interpreted separately from the calculation configuration.
The central scientific object is therefore not the isolated Elo value. It is the complete relationship:
[<br>\text{evidence} \rightarrow<br>\text{identity policy} \rightarrow<br>\text{calculation} \rightarrow<br>\text{published interpretation}.<br>]2. What rolling ratings are
A rolling rating table is recalculated repeatedly as the available evidence changes. The most visible trigger is the completion of a new game, but other triggers may include:
- importation of a missing game;
- removal of a duplicate;
- correction of an invalid result tag;
- normalization of an engine name;
- correction of a version label;
- addition of an event;
- exclusion of games declared invalid;
- changes in the rating-tool configuration.
The Top Chess Engine Championship provides a clear public example. Its rules state that the TCEC rating list is updated live after every official game. The same rules explain that version numbers are ignored in the rating file and that games lost on time or because of crashes are included. This produces a continuously developing family-level rating surface rather than an exact-binary historical catalogue.
This model is useful because it allows spectators and analysts to observe how accumulated evidence changes during an active competition. A newly completed game can affect:
- the two participating engines;
- the ratings of their previous opponents;
- the relative location of the connected pool;
- displayed ranks;
- uncertainty estimates;
- derived statistics such as expected score or likelihood of superiority.
The effect may be small, but the table remains conceptually dynamic.
In a jointly fitted model, the new result is not necessarily added only to the two visible ratings. The model is solved over a network of pairwise results. A modification in one part of a connected result graph can propagate through the estimated relationships among many participants.
Statistical research on dynamic paired-comparison systems treats competitor strengths as quantities that may change over time and emphasizes uncertainty in the estimated parameters. Glickman’s work on large dynamic paired-comparison experiments was motivated partly by the problem of rating large chess populations and developed a model capable of repeated estimation while accounting for variability in the estimates.
A rolling chess engine rating list is therefore best understood as a current analytical state, not as an immutable publication edition.
3. Why live tables are valuable
The instability of a rolling rating does not make it defective. It is a consequence of its purpose.
Live tables provide several legitimate benefits.
3.1 Immediate incorporation of evidence
A completed game becomes part of the public analytical surface without waiting for the end of a season or a monthly publication cycle.
3.2 Visibility during long competitions
Computer-chess events may contain hundreds or thousands of games. A rolling table gives the audience a structured view of progress that a simple standings table may not provide.
3.3 Early detection of anomalies
Unexpected movements can reveal:
- a naming inconsistency;
- an accidentally duplicated game;
- a disconnected subgroup;
- an engine entered with the wrong configuration;
- an unusual concentration of crashes or time losses;
- a rating-tool setting that differs from previous calculations.
3.4 Operational feedback
Tournament organisers can inspect whether the evolving database appears coherent before producing a final edition.
3.5 Provisional interpretation
A live table can show that an engine currently occupies a particular rating region or has a higher central estimate than another participant.
The appropriate language is conditional:
At the stated calculation cutoff, Engine A had the higher central rating estimate in the named rolling list.
The inappropriate language is universal:
Engine A is definitively stronger than Engine B.
The second sentence removes the time, list, evidence population and uncertainty that give the first sentence its meaning.
4. Why a live rating is not automatically a citable historical object
A scientific citation should allow a later reader to identify and recover the object that supported a claim. A continuously changing webpage may fail that requirement.
Suppose an article published on 4 August states:
Engine A was rated 3,520.
A reader opening the live table on 10 August may see:
- 3,527;
- a different rank;
- a different game count;
- a renamed engine;
- no Engine A entry at all because it was merged into a family identity.
The original statement may have been accurate when written, but the live destination no longer demonstrates it.
This is a general problem in the citation of dynamic datasets. DataCite guidance identifies several defensible approaches: citing a particular snapshot, citing a continuously updated dataset with an access date and time, or citing a time-stamped query that can be reproduced against a versioned database. It also warns that citing only the live dataset means that following the reference later may not recover the resource in the state originally used.
For a chess engine rating list, a minimal live citation should therefore contain:
- list name;
- publisher;
- calculation date;
- calculation time and timezone;
- game cutoff;
- access date and time;
- engine identity as displayed;
- rating and uncertainty;
- game count;
- publication status.
Even that is weaker than a frozen edition, because the destination itself may change. The stronger solution is to preserve an immutable snapshot.
5. Frozen snapshots create identifiable editions
A frozen snapshot is a preserved representation of the rating state at a defined publication boundary. It should not change silently after release.
Appropriate boundaries include:
- closure of a tournament;
- closure of a league stage;
- publication of an official monthly list;
- completion of an audited game pack;
- introduction of a major methodology change;
- migration to a new hardware profile;
- replacement of a neural network;
- restructuring of the engine pool.
The snapshot may be published as HTML, PDF, CSV, JSON or plain text. The format is less important than identity, completeness and recoverability.
A robust snapshot package should contain four layers.
5.1 Human-readable rating table
The visible table should report:
- engine or configuration name;
- rating estimate;
- confidence or error interval;
- number of games;
- average opposition where available;
- score or winning percentage where useful;
- rank;
- status.
The Swedish Chess Computer Association explicitly asks that quotations of its list include not only the rating figures but also the number of games and margin of error. Its public list displays rating, upper and lower error figures, games, winning percentage and average opponent. This is a strong example of treating uncertainty and sample size as part of the published claim rather than optional decoration.
5.2 Machine-readable output
A CSV or JSON representation allows independent checking, automated comparison and long-term reuse.
5.3 Calculation manifest
The manifest should record:
- rating software;
- software version or commit;
- command-line arguments;
- normalization rule;
- fixed anchor, if any;
- draw model or relevant parameters;
- minimum-game filters;
- inclusion and exclusion rules;
- engine identity policy;
- calculation timestamp.
5.4 Evidence package
The package should link to or include:
- the exact PGN database;
- audit report;
- tournament configuration;
- incident record;
- checksum manifest.
A snapshot becomes substantially more valuable when a reader can reconstruct the path from the published table back to the game population.
6. Hashes and reproducibility
File names are not sufficient identifiers for evidential objects.
Two files can have the same name and different content. A PGN pack called final-games.pgn may be corrected and reuploaded without changing the visible filename. A later reviewer would then be unable to determine which version produced the published table.
A snapshot manifest should therefore record cryptographic hashes, preferably using a contemporary algorithm such as SHA-256, for:
- PGN input;
- identity-mapping file;
- rating configuration;
- rating output;
- audit report;
- engine manifest, where applicable.
For example:
Snapshot ID: IJCCRL-2026-BLITZ-ORI-FINAL-R1
Calculation cutoff: 2026-08-04T14:00:00Z
PGN SHA-256: [hash]
Identity map SHA-256: [hash]
Ordo binary SHA-256: [hash]
Configuration SHA-256: [hash]
Rating output SHA-256: [hash]
The hash does not explain the methodology, but it verifies that two references concern the same bytes.
Scientific-data principles extend beyond the preservation of a final table. The FAIR framework states that findability, accessibility, interoperability and reusability apply not only to conventional datasets but also to algorithms, tools and workflows. A serious rating publication should therefore preserve enough of the analytical pipeline to make the output interpretable and reusable.
7. Historical recalculation is a different publication act
Historical recalculation means processing earlier evidence again under a later analytical state.
It can be legitimate and scientifically useful. It can also create confusion when the new result is displayed as though it were the number originally published.
Consider a 2024 game database recalculated in 2026. The new calculation might use:
- a corrected PGN population;
- a newer Ordo or BayesElo build;
- a revised draw model;
- a different rating anchor;
- renamed engines;
- merged engine families;
- separated exact versions;
- new games connecting an isolated pool;
- a different rule for crashes or time losses.
The 2026 output answers:
What ratings do we calculate now from the historical evidence under the current policy?
It does not necessarily answer:
What ratings did the organisation publish in 2024?
Those are distinct historical questions.
A mature archive should preserve both:
- Contemporaneous publication: the edition released at the time.
- Retrospective recalculation: the later reconstruction, clearly dated and labelled.
The two objects can be linked through a version or derivation relationship. DataCite recommends explicit version metadata and links such as “IsPreviousVersionOf,” “IsNewVersionOf,” “HasVersion” and “IsVersionOf” when major versions of a research object are published.
An IJCCRL archive could use an analogous human-readable policy:
Original edition:
IJCCRL Blitz Original UCI — 2026-08-04
Corrected edition:
IJCCRL Blitz Original UCI — 2026-08-07, Correction 1
Retrospective recalculation:
IJCCRL Blitz Original UCI — Recalculated under Rating Method 2027.1
The labels prevent a later recalculation from erasing the evidential status of the original edition.
8. Why ratings can move when an engine plays no new games
This effect can appear counterintuitive.
Suppose Engine A played only Engine B. Engine B also played Engines C and D. A correction to the C–D result changes the fitted relationships within the connected pool. Because B connects A to the rest of that pool, the inferred position of A may also shift.
Other causes include the following.
8.1 Global normalization
Relative rating systems require a scale convention. Adding a constant to every rating leaves expected score differences unchanged. Software therefore applies an average, offset or fixed reference.
Ordo, for example, uses a default average rating and allows the operator to select another average or fix a participant as a reference anchor. BayesElo similarly provides an offset operation. A change in the anchor can move every printed rating without changing any pairwise strength differences.
8.2 Pool reconnection
Two previously disconnected result components cannot be placed reliably on one relative scale without an external constraint. When new games connect them, their relative location becomes estimable and the displayed ratings may move sharply.
8.3 Identity consolidation
If Engine X 1.0, Engine X 1.1 and Engine X 1.2 are merged into Engine X, the combined result population differs from every individual-version population.
8.4 Removal of invalid evidence
Deleting duplicated, malformed or administratively invalid games changes the likelihood surface from which the ratings are estimated.
8.5 Model or parameter changes
Changing the handling of draws, priors, scale, confidence calculations or filtering rules may alter the entire table.
Therefore, the statement “this engine played no new games” does not imply that its recomputed rating must remain fixed.
9. Version policy determines what the rating represents
The word “engine” can denote several different statistical identities.
A publication might rate:
- an engine family;
- an exact release;
- an exact executable;
- a source-code commit;
- an engine plus neural network;
- an engine plus parameter file;
- an engine plus hardware profile;
- an engine plus UCI configuration.
These are not equivalent objects.
9.1 Family-level continuity
Under a family policy, new versions contribute to one continuous identity. TCEC’s published rating policy explicitly ignores version numbers. The advantage is continuity and a compact long-term table. The cost is that the rating does not describe one reproducible binary.
9.2 Exact-version publication
Each release receives a separate row. This improves reproducibility and makes progress between versions visible, but fragments the evidence and may produce many low-sample entries.
9.3 Active-version replacement
The list displays only the current version while older versions remain in the archive. This keeps the current table readable but requires preserved snapshots if historical claims are to remain recoverable.
9.4 Configuration-level identity
A change in threads, hash, tablebase access, network or important UCI parameters creates a new configuration identity even when the engine name is unchanged.
A scientific snapshot should state its policy explicitly. Otherwise a reader cannot know whether a rating movement represents:
- software improvement;
- a new neural network;
- more games;
- altered hardware;
- a recalibrated pool;
- an editorial renaming.
A recommended identifier is:
Engine family
Version or commit
Binary hash
Network hash
Architecture
Threads
Hash memory
Tablebase policy
Relevant UCI options
Not every public table needs to display all fields, but the snapshot manifest should preserve them.
10. Engine identity and the problem of renamed participants
Engine names in PGN files are often treated as if they were reliable database keys. They are not.
Names may vary because of:
- punctuation;
- architecture suffixes;
- capitalization;
- release-date formats;
- local rebranding;
- truncated headers;
- inconsistent network labels;
- manual typing;
- updated UCI identification strings.
For example, the following could accidentally become separate participants:
EngineX 4.0
Engine X 4.0
enginex-4.0-avx2
EngineX 4
The opposite error is also possible: two materially different configurations may be merged because they share one simplified name.
A historical recalculation should therefore use a version-controlled identity map. Each transformation should be reviewable:
Raw PGN name → canonical participant ID
The map itself should be hashed and archived. If it changes, the recalculation should receive a new edition identifier.
Identity corrections should also preserve the raw source. The correct procedure is not to destroy the original PGN header, but to retain the original record and apply a documented normalization layer.
11. Frozen snapshots preserve editorial meaning
A snapshot does more than freeze numbers. It freezes the publication’s interpretive context.
Imagine a final event report stating:
Engine A finished the cycle as the highest-rated participant.
Months later, a global recalculation places Engine B above Engine A. Was the report wrong?
Not necessarily. It may have accurately described the final snapshot available when the event closed. The later table answers a different question using a changed evidence population or policy.
Without the frozen edition, the historical sentence becomes difficult to defend. With the edition, the publication chain remains intelligible:
- this was the table at event closure;
- this was the evidence used;
- this was the methodology;
- this later recalculation superseded the estimate for current analytical purposes;
- the original edition remains the source for contemporaneous historical claims.
Dated SSDF list editions illustrate this principle. SSDF rating lists were published as identifiable editions, including editions appearing in the ICGA Journal with publication metadata and DOI records. The 2023-05 edition, for example, is an independently identifiable scholarly publication rather than an unversioned webpage that silently changes.
The historical value lies not only in the ranking but in the recoverable state of the publication.
12. Corrections should be preserved, not concealed
Errors are unavoidable in long-running data systems. Scientific quality is measured partly by how corrections are handled.
Potential rating-publication errors include:
- duplicated games;
- omitted games;
- incorrect results;
- malformed PGN tags;
- wrong engine mapping;
- wrong time-control classification;
- accidental inclusion of testing games;
- accidental exclusion of valid crash losses;
- incorrect rating parameters;
- incorrect table labels;
- broken download packages.
A correction policy should answer five questions:
- What was wrong?
- Which objects were affected?
- What was changed?
- Did the ratings or only the presentation change?
- Where can the previous edition be recovered?
Corrections can be classified as follows.
Type A: editorial correction
Examples include spelling, formatting or a broken hyperlink. The rating output does not change.
Type B: metadata correction
An engine author, country, architecture or configuration field changes, but the game population and rating calculation remain unchanged.
Type C: evidence correction
Games are added, removed or modified. Ratings must be recalculated.
Type D: methodology correction
The rating software, parameters, identity policy, normalization or inclusion rules change.
Types C and D should create a new snapshot edition. The original should remain accessible with a visible label such as:
Superseded: evidence correction issued 2026-08-07
Deleting the earlier table removes evidence of what readers actually saw and makes previous citations impossible to interpret.
13. “As published then” and “calculated now”
Historical research requires both perspectives.
As published then
This is the appropriate source for questions such as:
- Which engine led the published list at the end of the season?
- What error margin did the organisation report?
- What evidence was available to readers?
- How was an engine represented in contemporary coverage?
Calculated now
This is appropriate for questions such as:
- What rating estimates result from the corrected historical PGN collection?
- How does a uniform modern method rank engines across several archived events?
- What happens when version identities are normalized consistently?
- How does a revised statistical model change the historical table?
The first is a publication-history object. The second is a retrospective analytical object.
A scientific website should not use one label for both. Recommended terminology includes:
- Contemporaneous snapshot
- Corrected contemporaneous edition
- Retrospective recalculation
- Current rolling table
This vocabulary allows readers to understand why two legitimate tables can report different numbers for the same engine and period.
14. Comparison of three publication modes
Public computer-chess projects illustrate different, useful modes of rating publication.
14.1 TCEC: continuous family-level operational rating
TCEC’s live rating file is designed to support an active competition environment. It updates after official games and treats engine families continuously by ignoring version numbers. Its primary strength is immediacy.
14.2 CCRL: continuously maintained test-list surface
CCRL publishes rating tables with test conditions, ratings, error figures and game counts. Its index identifies the time-control framework and related testing conditions, while its tables expose substantial participant-level evidence. This supports detailed comparison within the CCRL environment, although a reader should still record an access date when citing a mutable table.
14.3 SSDF: dated historical editions
SSDF combines a long-running public list with clearly dated list publications. Its insistence that rating, game count and error margin be quoted together reflects a publication culture in which uncertainty and evidence volume are integral to the claim.
These approaches should not be reduced to a simplistic contest over which organisation is “best.” They reflect different publication purposes:
- operational continuity;
- cumulative testing;
- historical editioning.
A serious IJCCRL system can adopt useful elements from all three without copying their exact identity or methodology.
15. A recommended IJCCRL publication lifecycle
IJCCRL can integrate rolling ratings, snapshots and historical recalculation through a defined lifecycle.
Stage 1: event initialization
Publish:
- event ID;
- official name;
- track;
- time control;
- participant manifest;
- engine-identity policy;
- opening policy;
- rating method;
- planned snapshot boundaries.
Stage 2: rolling publication
The live or blog layer may show provisional ratings.
Every display should include:
Status: Provisional
Calculated: date and time
Games included: number or cutoff
Method: tool and configuration
The page should avoid presenting the numbers as a final historical edition.
Stage 3: audit closure
When the competition ends:
- validate the PGN;
- verify mirrored openings;
- inspect result totals;
- resolve crashes, timeouts and adjudications;
- freeze the final evidence pack;
- calculate hashes;
- publish the audit status.
Stage 4: event-close snapshot
Generate an immutable snapshot containing:
- final rating table;
- uncertainty;
- games;
- participant manifest;
- method note;
- rating configuration;
- hashes;
- correction policy.
Stage 5: canonical distribution
Each publication surface should retain one role:
- Ratings Lists: current numerical surfaces;
- Rules & Audit: methodology and validation rules;
- Downloads: exact evidence packages;
- Archive: frozen historical editions;
- Winners: final champion identity;
- Events: calendar and competition status;
- PGN Games History: cumulative game evidence;
- Blog or Live: provisional developments.
Stage 6: later correction
If evidence or methodology changes:
- preserve the original;
- publish a correction notice;
- create a new edition;
- explain rating effects;
- link both editions.
Stage 7: retrospective recalculation
If IJCCRL later applies a uniform method across historical events, publish the result as a new analytical collection, not as a silent replacement of the original snapshots.
16. Minimum snapshot manifest
The following manifest would satisfy most practical requirements.
Publication title:
Snapshot identifier:
Publication status:
Original publication date:
Calculation date and time:
Timezone:
Event identifier:
Track:
Time control:
Opening policy:
Tablebase policy:
Hardware profile:
Rating tool:
Tool version or commit:
Command line:
Normalization:
Anchor:
Confidence level:
Minimum-game policy:
Identity policy:
Exact-version or family-level:
Engine manifest reference:
Engine-manifest hash:
Network hashes:
Relevant UCI settings:
PGN filename:
PGN SHA-256:
Number of games:
Included event range:
Excluded games:
Exclusion reasons:
Rating output filename:
Rating-output SHA-256:
Audit report:
Audit-report SHA-256:
Previous edition:
Next edition:
Correction notice:
Method note:
Permanent archive location:
This may look extensive, but most fields can be generated automatically. The burden is low compared with the long-term value of reproducibility.
17. Editorial review procedure
Before publishing a claim based on rolling chess engine ratings, the editor should open four objects in parallel:
- the rating table;
- the method note;
- the event or database manifest;
- the supporting PGN package.
The editor should then verify:
- exact engine identity;
- configuration;
- rating value;
- uncertainty;
- number of games;
- calculation cutoff;
- provisional or final status;
- correct source destination.
A second reviewer should attempt to reproduce the claim from the public evidence.
The review should ask:
- Can the cited edition be recovered?
- Is the rating from a live or frozen table?
- Does the engine name represent a family or exact version?
- Is the value an original edition or later recalculation?
- Is an access date needed?
- Is the uncertainty visible?
- Does the text imply causation that the table cannot establish?
- Would the sentence remain intelligible if the current live table changed tomorrow?
When a claim fails these checks, the solution is usually to narrow the language or create a snapshot.
18. Observation, calculation and interpretation
A reliable publication separates three layers.
Observation
An observation is a recorded fact from the evidence system:
- a game result;
- a crash;
- a timeout;
- a configuration setting;
- a PGN tag;
- a hardware allocation.
Calculation
A calculation is the transformation of those observations through a defined model:
- Ordo output;
- BayesElo output;
- confidence intervals;
- expected scores;
- ranking.
Interpretation
An interpretation is the sentence presented to readers:
Engine A occupied the highest estimated rating position at the event-close cutoff.
Confusing the layers creates overclaiming.
A table may show that one engine scored differently from another. It does not, by itself, establish that a particular search modification, evaluation term, neural network or CPU characteristic caused the difference. Causal attribution requires a controlled comparison designed to isolate that variable.
A corrected PGN can change the observation layer and therefore the calculation. A revised explanation may change only the interpretation. The correction notice should identify which layer changed.
19. Worked publication example
Assume a live list contains the following provisional rows:
1. Engine A — 3518 ± 12 — 1,240 games
2. Engine B — 3513 ± 11 — 1,390 games
An initial article draft states:
Engine A is conclusively stronger than Engine B.
The claim is not justified. The difference is five rating points, the uncertainty intervals overlap, the table is rolling and the identities may represent engine families rather than exact executables.
A defensible revision is:
At the stated calculation cutoff, Engine A held a five-point higher central estimate than Engine B in the named provisional list. The published uncertainty does not support treating the small gap as a universal or conclusive strength difference.
The editor records:
List: named publication
Status: provisional
Calculation cutoff: exact date and time
Engine identity policy: family-level
Games: displayed counts
Rating method: named tool and configuration
Access time: exact timestamp
At event closure, the organiser audits the PGN and discovers one duplicated mirrored pair. The pair is removed, producing:
1. Engine B — 3515 ± 11
2. Engine A — 3514 ± 12
The final publication should not pretend that the first table never existed. The archive should contain:
- the provisional rolling state or its dated report;
- the audit finding;
- the corrected PGN hash;
- the final snapshot;
- an explanation that the final ordering changed after evidence correction.
Two years later, IJCCRL recalculates the event using a new historical methodology and exact-version identities. Engine A becomes 3522 and Engine B 3519.
That later table should be labelled:
Retrospective recalculation — method version 2028.1
It should not replace the event-close snapshot, because it answers a different analytical question.
20. Reader checklist
Before quoting a rolling rating:
- record the date, time and timezone;
- record the list name;
- state whether the value is provisional;
- include the engine identity as displayed;
- include the number of games;
- include uncertainty when available;
- identify the time control and pool;
- preserve an access date;
- prefer a frozen snapshot for durable claims.
Before citing a frozen snapshot:
- verify its permanent identifier;
- verify the PGN hash;
- verify the method note;
- distinguish original from corrected editions;
- check whether the identity is family-level or exact-version.
Before using a historical recalculation:
- state the recalculation date;
- identify the historical game population;
- identify changes from the original method;
- identify changes to engine mappings;
- avoid describing the recalculated number as the rating “published then.”
Frequently asked questions
Are live ratings official?
They may be official estimates within the publisher’s live system. “Official” does not mean immutable. A live official table is still a dynamic resource and should be cited with a calculation or access timestamp.
Why can an old engine’s rating change when it played no new games?
Ratings are relational estimates. Changes to connected opponents, normalization, identity mappings, excluded games or model settings can move the engine’s estimate.
Should an organisation delete an incorrect snapshot?
No. It should preserve the snapshot, mark it as superseded or corrected, publish the reason and link to the replacement.
How often should snapshots be created?
At meaningful publication boundaries: event closure, monthly release, season closure, major pool reconstruction or methodology change. Creating a snapshot after every game is usually unnecessary if the rolling system already preserves an event log.
Is a screenshot sufficient?
A screenshot can document visual appearance, but it is not a complete scientific package. It may omit settings, hashes, machine-readable data and the underlying games.
Can a live webpage be cited without a snapshot?
Yes, but the citation should include access date and time, and the article should acknowledge that the resource may later change. A frozen edition is preferable for claims expected to remain verifiable.
Should exact engine versions always receive separate ratings?
Not necessarily. Family-level and exact-version policies answer different questions. The essential requirement is to state the policy and apply it consistently.
Does recalculation prove that the original publication was wrong?
No. A later recalculation may use different evidence or methodology. The original may remain an accurate record of what was known and published at the time.
Are ratings from different lists directly comparable?
Not automatically. Differences in game populations, hardware, time controls, openings, engine identities, rating methods and scale anchors can make the absolute values non-equivalent.
Conclusion
Rolling ratings, frozen snapshots and historical recalculations are complementary components of a mature chess engine rating publication system.
The rolling table provides immediacy. It incorporates current evidence and supports the interpretation of an active competition. Its numbers remain conditional on a moving database and should be quoted with timestamps, status and game counts.
The frozen snapshot creates a citable edition. It preserves the table, evidence cutoff, identity policy, rating configuration, uncertainty and source package. It allows a later reader to recover what the publisher reported at a particular moment.
The historical recalculation creates a new analytical object. It can correct evidence, harmonize identities, reconnect pools or apply a revised model. Its output may be more useful for present-day comparison, but it must not erase the contemporaneous edition or be misrepresented as the value originally published.
The governing editorial principle is simple:
Preserve what was published, identify what has changed and explain what has been recalculated.
For IJCCRL, this principle can be implemented through a connected evidence chain. The current Ratings hub can carry rolling numerical surfaces. Rules & Audit can define methods and correction policy. Downloads can preserve exact PGN packages and manifests. Archive can protect frozen editions. Event and blog pages can report provisional developments without converting them prematurely into permanent historical claims.
A chess engine rating becomes reliable public evidence only when the reader can identify the list conditions, participant identity, game population, method, uncertainty and publication state. The purpose of a scientific rating publication is not to make uncertainty disappear. It is to preserve enough information for uncertainty, revision and historical change to be interpreted correctly.
Sources and technical references
- Coulom, R. Bayesian Elo Rating. Official BayesElo documentation and software description.
- Ballicora, M. A. Ordo: Ratings for Chess and Other Games. Official source repository and usage documentation.
- Glickman, M. E. “Parameter Estimation in Large Dynamic Paired Comparison Experiments.” Journal of the Royal Statistical Society: Series C (Applied Statistics), 48(3), 377–394. doi:10.1111/1467-9876.00159.
- Glickman, M. E., and Jones, A. C. “Models and Rating Systems for Head-to-Head Competition.” Annual Review of Statistics and Its Application, 12, 259–282. doi:10.1146/annurev-statistics-040722-061813.
- Top Chess Engine Championship. TCEC Rules, engine-rating policy and live-update provisions.
- Computer Chess Rating Lists. CCRL 40/15 Rating List and Testing Index.
- Swedish Chess Computer Association. The SSDF Rating List. Public list and quotation guidance.
- Sandin, L. “The SSDF Chess Engine Rating List, 2023-05.” ICGA Journal, 45(1), 28–30. doi:10.3233/ICG-230231.
- Wilkinson, M. D., et al. “The FAIR Guiding Principles for Scientific Data Management and Stewardship.” Scientific Data, 3, 160018. doi:10.1038/sdata.2016.18.
- DataCite. Citation of Dynamic Datasets. Guidance on snapshots, access dates and time-stamped queries.
- DataCite. Versioning. Guidance on minor and major versions and relations between research objects.
- Chess.com. Computer Ratings: November 2020. Supplementary example of a dated computer-rating publication.
Jorge Ruiz Centelles
Filólogo y amante de la antropología social africana