Table of Contents

How to Cite a Chess Engine Rating List Correctly

A chess engine rating is not a free-standing physical measurement. It is a statistical estimate produced from a defined collection of games, a selected population of opponents, a rating model and a specific testing environment. Consequently, citing only an engine name and an Elo number is rarely sufficient.

A statement such as “Engine A is rated 3600” appears precise but leaves almost every important methodological question unanswered. Which rating project published the number? Was it a bullet, blitz or longer-time-control table? Did the entry refer to a single binary, a network-engine combination or an aggregated engine family? How many games supported the estimate? What uncertainty was reported? When was the table calculated? Were crashes, time forfeits or disconnected games included? Which hardware and resource profile were used?

Without those details, the number may be real but the citation is incomplete.

For readers of chess engines ratings lists, correct citation is part of correct interpretation. It allows another reader to recover the same publication context, distinguish a provisional figure from a mature estimate and evaluate whether the cited number actually supports the claim made in the surrounding text.

This article presents a practical citation framework for researchers, chess-engine developers, tournament organisers, journalists, technical bloggers and rating-list publishers. Its purpose is not to impose one universal bibliographic style. Instead, it defines the information that should survive when a rating value is transferred from a public table into an article, report, forum post, release note, comparison or historical record.

1. A rating-list citation is a reproducibility record

Ordinary web citation answers a basic question: where did this information come from?

A technically complete rating-list citation must answer a more demanding question:

What exact published measurement did the author use, and under what conditions was that measurement meaningful?

This distinction matters because most public rating lists are dynamic. New games are added, engine versions change, errors are corrected and ratings are recalculated. A table viewed in July may no longer show the same values in September.

The citation must therefore preserve more than the location of the page. It should preserve the identity of the measurement.

A useful way to represent the minimum citation record is:

Citation record = project + table + snapshot date + engine identity + configuration + rating + uncertainty + games + method + conditions + source + access date

Not every publication needs to print every field in the same sentence. A short article may place the methodological conditions in a footnote or reference entry. A technical report may include them in a data table. A rating-list comparison may introduce the common conditions once and then cite individual entries more compactly.

Nevertheless, the information should remain recoverable somewhere in the publication.

The broader principles of research-software citation are relevant here. The FORCE11 Software Citation Principles emphasise unique identification, persistence, accessibility and specificity, including identification of the particular software version or platform variant used. Those principles map naturally onto chess-engine citation because an engine family name alone may conceal materially different binaries, networks, architectures or releases.

2. Name the rating project

The first required field is the organisation or project responsible for the rating publication.

“According to a chess engine rating list” is not an adequate attribution. It tells the reader what type of source was consulted but not which source produced the number.

Examples of distinct public rating contexts include:

CCRL 40/15;
CCRL Blitz;
the SSDF rating list;
TCEC’s internally calculated ratings;
an IJCCRL Original UCI Track rating surface;
an IJCCRL Derived Stockfish Track rating surface;
a private test league;
an engine author’s local gauntlet;
a temporary tournament-performance table.

These sources do not constitute one global database. They may differ in hardware, time control, opening policy, opponent population, engine-version policy, treatment of incidents and rating calculation.

The responsible organisation should normally be treated as the corporate author of the rating table. The engine developer is the author of the software, but not necessarily the author of the rating list. Confusing these roles can produce misleading references.

A sound citation begins with a formulation such as:

Computer Chess Rating Lists, CCRL 40/15…

or:

Swedish Chess Computer Association, SSDF Rating List…

or:

IJCCRL, Bullet Rating List — Original UCI Track…

This immediately identifies the publication authority.

3. Identify the exact table, track or time control

Naming the project is necessary but not always sufficient. Large rating projects commonly publish more than one list.

CCRL, for example, distinguishes its 40/15 work from faster testing and other formats. Its 40/15 documentation defines a repeating control equivalent to 40 moves in 15 minutes on a reference processor and separately declares tablebase, pondering, hash and opening-book conditions. A citation that says only “CCRL” removes the table identity that gives the number its context.

The table name should therefore include the relevant division whenever the project publishes more than one rating environment.

Examples include:

CCRL 40/15 Rating List — All Engines
CCRL Blitz Rating List
SSDF Rating List, 2023-12-31 edition
TCEC official global ratings
IJCCRL Bullet Rating List — Original UCI Track
IJCCRL Classical Rating List — Derived Stockfish Track

For IJCCRL, track separation is particularly important. Original UCI engines and Stockfish-derived engines should not be treated as though they automatically belong to one homogeneous publication pool. The current IJCCRL ratings architecture explicitly separates tracks, time controls, publication status and sample maturity.

A citation that omits the track can therefore change the meaning of the claim.

Instead of writing:

Obsidian was rated X by IJCCRL.

write:

On the IJCCRL Bullet Rating List — Original UCI Track, calculated from the stated audited corpus, Obsidian [exact version] had a published rating of X.

The second sentence identifies the measurement surface and prevents accidental comparison with an unrelated derived-engine or classical list.

4. Record the calculation, publication or snapshot date

Rating pages change. The date is therefore part of the evidence, not an optional decoration.

Three dates may be relevant:

Calculation cutoff: the final game or dataset date included in the calculation.
Publication or update date: the date displayed by the rating publisher.
Access date: the date on which the citing author consulted the source.

When the rating page is static and clearly dated, the publication date may be sufficient for ordinary citation. When the page changes continuously, both the displayed calculation date and the access date should be recorded.

For a live or frequently updated page, a timestamp can be useful:

Accessed 28 July 2026 at 14:30 CEST.

A time zone should be included when the precise time matters. This is especially relevant during active tournaments, where another set of results may be added later on the same day.

The distinction between update date and access date should not be blurred. “Accessed 28 July” means only that the author opened the source on that date. It does not prove that the rating calculation itself was produced on that date.

A complete technical citation might say:

Rating calculation updated 26 July 2026; accessed 28 July 2026.

If a permanent snapshot exists, it is preferable to a mutable homepage. Archive pages, downloadable text versions, dated exports and preserved tables are stronger evidence because they allow a later reader to recover the same state.

5. Identify the engine exactly

The engine name must be as specific as the source permits.

A family name such as “Stockfish,” “Lc0,” “Komodo,” “Obsidian” or “Reckless” may refer to many releases. Even a formal version number may be insufficient when the list distinguishes processor architecture, number of CPUs, network weights or hardware profile.

A precise engine identity may include:

family name;
release or development version;
build date;
commit identifier;
architecture;
instruction-set build;
CPU or GPU designation;
thread or core count;
neural-network identifier;
evaluation file;
relevant custom configuration.

The correct level of specificity depends on the table.

If a list distinguishes:

Stockfish 18 64-bit 4CPU

then the citation should not silently shorten it to:

Stockfish 18

if the number of CPUs is material to the table.

If an NN engine is listed with a network identifier, the network should be preserved when it is part of the participant identity. Two runs of the same executable with different networks may represent meaningfully different playing configurations.

If a development engine is named by date, revision or commit, that identifier should remain visible. “Development version” is too broad when dozens of commits may separate two builds.

This requirement does not mean adding information that the source does not provide. A citation should never invent an architecture or configuration from general knowledge. It should reproduce the identity used by the rating publisher and add external configuration details only when those details are independently documented.

6. Respect family aggregation policies

Some rating projects calculate one entry per exact version. Others aggregate multiple versions under a family name.

These are fundamentally different publication models.

TCEC’s published archive documentation explains that its global rating calculation uses Ordo, includes games across seasons and aggregates all versions of an engine under a single name. It also describes exclusions affecting certain losses and engines. Therefore, a TCEC family rating should not be cited as though it represented one exact binary release.

A correct citation would say:

TCEC’s global family rating for Engine A…

not:

Engine A version 4.2 was rated X by TCEC…

unless the cited table actually isolates version 4.2.

When the publication aggregates versions, the citation should state that policy explicitly:

The rating is a family-level aggregate across versions under TCEC’s published global-rating policy.

This qualification prevents a common category error: assigning a family-level estimate to one particular release.

Conversely, when a list keeps every release separate, the citation must preserve the exact version rather than collapsing several entries into an informal family average.

7. Report the rating exactly as published

The central rating estimate should be copied accurately.

Do not:

round a rating without saying so;
remove a decimal place selectively;
convert asymmetric uncertainty into a symmetric value without explanation;
infer a rating from the displayed rank;
substitute a tournament performance estimate for the published list rating;
combine ratings from different lists into an undocumented average.

If the source reports an integer value, quote the integer. If it reports decimal precision, preserve the relevant decimals unless the publication deliberately adopts a consistent rounding rule.

A difference of one or two Elo points should not be rhetorically inflated. In most serious rating environments, such a difference is much smaller than the uncertainty attached to the estimates.

A citation should support the text’s level of precision. If the article says only that two engines occupied the same broad rating region, exact single-point precision may not be necessary in the prose, although the full values can remain in a table or note.

If the article claims that one engine led another by exactly 14 Elo, then the date, uncertainty and shared calculation context become essential.

8. Include uncertainty

A rating estimate without uncertainty can imply more precision than the data supports.

The uncertainty field may be expressed as:

a symmetric plus/minus value;
separate positive and negative margins;
a confidence interval;
a credible interval;
a standard error;
another project-specific statistic.

These terms should not be treated as interchangeable unless the methodology says that they are.

The SSDF rating page is unusually explicit about quotation practice. It asks publications quoting the Swedish list to include not only rating figures but also the number of games and margin of error. Its table displays positive and negative error margins alongside the central rating and game count.

That policy expresses a general principle that should be adopted beyond SSDF: uncertainty belongs to the reported result.

A complete quotation may look like:

Engine A: 3582, +50/−48, 200 games.

If a list reports a symmetric interval:

Engine A: 3582 ± 49 Elo, 200 games.

The second form should be used only when that symmetric presentation appears in the source or has been calculated transparently from the original values.

When two engines’ intervals overlap substantially, a writer should avoid definitive language such as “proved stronger” unless other evidence justifies it.

A safer sentence is:

Engine A had the higher central estimate in this edition, although the reported uncertainty does not support treating the small numerical difference as a universal or final strength distinction.

9. Include the number of games

Game count is one of the most important indicators of rating maturity.

A rating based on 120 games and a rating based on 5,000 games do not carry the same evidential weight, even if both tables display a precise integer.

The game count helps readers evaluate:

sample maturity;
exposure to the opponent pool;
sensitivity to recent results;
uncertainty;
possible imbalance in the data;
whether the entry remains provisional.

The citation should therefore include the entry’s game count whenever it is available.

The total database size may also be relevant, but it is not a substitute for the number of games played by the cited engine. A project may contain millions of games while a new engine entry is based on only a few hundred.

A robust sentence might read:

In the dated table, Engine A was listed at 3510 Elo with a reported uncertainty of +18/−17 after 740 games.

This is much more informative than:

Engine A was rated 3510.

10. State whether the value is provisional or final

Active rating systems often publish interim values before the underlying competition cycle has closed.

Provisional ratings can be useful. They help readers follow an event and understand how new results are changing a table. The problem arises when provisional values are cited as though they were final, stable or long-term measurements.

The publication status should therefore be reproduced:

provisional;
interim;
live;
event-stage;
official;
closed;
audited;
recalculated;
historical;
under rebuild.

For IJCCRL, the distinction between provisional, event-stage and officially closed surfaces is part of the rating-publication architecture. The rating hub states that scientific closure should not be claimed where the underlying evidence is still incomplete or methodologically unstable.

A correct provisional citation might say:

On the provisional IJCCRL Blitz Original UCI table, after 180 accepted games per engine and before final audit closure, Engine A held a central estimate of X.

The qualifiers should appear in the main sentence, not be hidden at the bottom of the article.

11. Do not detach the rating from the time control

Time control is part of what the rating measures.

An engine may scale differently across bullet, blitz and classical play. A ranking observed at 60 seconds plus increment does not automatically predict the same ordering at a substantially longer control.

At minimum, the citation should identify:

the named rating table;
the nominal time control;
whether the control uses a fixed game time, moves-per-period system or increment;
any published hardware-equivalence rule.

CCRL 40/15, for example, defines its control by reference to 40 moves in 15 minutes on a benchmark machine and uses a repeating period. Its documentation also explains that equivalent controls are calibrated for different machines.

A technical citation should preserve that distinction rather than converting it casually into “15-minute chess.”

Likewise, an IJCCRL citation should distinguish controls such as:

Bullet 60s+2s;
Blitz 300s+2s;
Classical 40m+2s;

when those are the actual published environments.

12. Record the hardware and resource class

Hardware affects engine performance. A rating table is meaningful only inside the resource environment that produced its games.

The level of detail required depends on the claim.

For a general article, a concise hardware class may be sufficient:

CPU rating list, four threads per engine.

For a technical report, relevant fields can include:

processor model or benchmark equivalence;
physical cores or engine threads;
GPU model;
memory allocation;
hash size;
large-page policy;
operating system;
NUMA policy;
tablebase storage;
architecture-specific binary;
pondering;
move overhead;
network or evaluation file.

Not every rating project uses identical physical machines. Some normalise time controls by benchmark. Others use one fixed server. Still others combine tests from multiple contributors under a shared conditions policy.

The citation should not imply hardware homogeneity unless the source documents it.

A useful phrase is:

under the project’s published four-thread hardware-equivalence conditions.

This is more accurate than naming one processor if the games were collected across several calibrated systems.

13. Preserve the opening policy

Openings influence the statistical environment of engine testing.

A rating project may use:

generic opening books;
fixed opening suites;
random starting positions;
balanced or unbalanced lines;
fixed opening depth;
mirrored games with reversed colours;
engine-supplied books;
no book.

CCRL’s 40/15 conditions allow generic books under a maximum line length and require the same book within a tournament or match, while disabling engine-specific books for participating engines.

Other projects may use paired openings so that both engines play the same position once with each colour. In IJCCRL’s audit framework, mirrored-pair integrity and pair ratio zero are explicit publication concerns.

A full bibliography entry does not always need the opening-book filename. However, the article should identify the opening policy whenever it is material to the claim.

For example:

The comparison comes from a mirrored-opening event in which each line was played once with each colour.

That statement tells the reader that the result was not generated from an unrestricted sequence of unrelated openings.

14. Identify tablebase and adjudication conditions

Endgame tablebases and adjudication rules can affect which results enter the dataset and how games terminate.

Relevant fields may include:

tablebase family;
maximum number of pieces;
GUI or engine tablebase access;
50-move-rule treatment;
win adjudication;
draw adjudication;
manual decisions;
crash policy;
timeout policy;
restart policy;
disconnected-game policy.

These details become essential when an article discusses individual results, incidents or differences between rating projects.

A broad citation may point to the project’s method page. A claim about a specific disputed game should cite the event rules and audit record directly.

For IJCCRL, Rules & Audit is the methodological surface that explains legality, terminations, mirrored openings, incident handling and publication artifacts.

The rating page should carry the number. The methodological citation should explain why that number includes the games it includes.

15. Name the rating method

Elo values are outputs of a model. The method should therefore be identified.

BayesElo is described by Rémi Coulom as a tool that reads PGN game records and estimates Elo ratings.

Ordo is designed to calculate ratings for chess engines or players using an Elo-related but distinct model and algorithm, considering the result set jointly to maintain consistency among ratings.

A citation should state whether the table used:

Ordo;
BayesElo;
EloStat;
a custom logistic fit;
a performance-rating calculation;
a weighted update;
another published method.

The method name alone may not be sufficient when non-default parameters are important. A technical note may also need:

rating anchor or reference engine;
fixed average;
White-advantage treatment;
draw model;
confidence level;
connected-pool policy;
prior or regularisation settings;
exclusion filters;
rounding policy.

The purpose is not to overload every reader with statistical detail. The purpose is to prevent an Elo number from appearing to be independent of the model that generated it.

16. State the rating scale or normalisation policy

Relative ratings require a reference scale.

A list may:

fix one engine at a chosen value;
preserve a historical average;
normalise the population mean;
use an external anchor;
inherit a previous official scale;
publish only differences;
calculate performance values within a single event.

Without a declared anchor, the absolute numbers can shift while the relative relationships remain similar.

Therefore, comparisons across independently normalised lists are dangerous.

Suppose Engine A is rated 3600 on List 1 and 3550 on List 2. That does not prove that Engine A became 50 Elo weaker. The two lists may use different anchors, pools, methods, dates and conditions.

A correct cross-list sentence should say:

Engine A was assigned a higher numerical rating on List 1 than on List 2, but the values are not directly interchangeable because the lists use different pools and rating scales.

It should not say:

List 1 proves Engine A is 50 Elo stronger.

17. Describe the opponent pool

Ratings are relational. An engine does not generate an Elo value alone.

Its estimate depends on:

which opponents it played;
how often it played them;
the strength distribution of the pool;
whether the comparison graph is well connected;
whether versions are separate or aggregated;
which results were excluded;
the age and diversity of the database.

A list dominated by elite contemporary engines does not have the same structure as a historical list containing computers and engines from several decades. A closed ten-engine league does not create the same rating object as a long-term database containing thousands of programs.

The citation need not enumerate every opponent, but it should identify the population when that information is necessary to understand the claim:

within the ten-engine Original UCI Bullet pool…

or:

in the complete historical SSDF pool…

or:

in TCEC’s global family-level database…

This language prevents the rating from being interpreted as a universal score detached from its population.

18. Distinguish rating, rank, score and tournament performance

Four quantities are commonly confused:

Rating

A model-based estimate of relative strength derived from a game dataset.

Rank

The position of an entry after sorting a particular table.

Tournament score

The number of points earned in one event.

Performance rating

An estimate based on performance against opponents in a specified event or block.

An engine can win a knockout tournament without holding the highest long-term rating. An engine can lead a rating table without winning every event. A short tournament performance can exceed or fall below the engine’s longer-term estimate.

These outcomes are not contradictions. They answer different questions.

A citation should identify which quantity is being reported:

Engine A won the match 14.5–9.5.

Engine A ranked third in the dated rating table.

Engine A had a published rating of 3512 ± 11.

Engine A produced an event performance estimate of approximately 3540.

The terms should not be substituted for one another.

19. Cite the table, not only the homepage

A project homepage is better than no source, but it is usually weaker than the exact table.

The ideal destination is:

a dated or stable rating table;
an archived snapshot;
a downloadable text, CSV or PDF edition;
the specific rating surface;
the general project homepage only when no more precise source exists.

The method page should be cited separately when the claim depends on conditions not visible in the table.

For example, a technical article may need two references:

the exact rating table for the numerical value;
the testing-conditions page for time control, hardware and opening policy.

This division produces a cleaner evidence chain than asking one general homepage to support every statement.

20. Use an access date for dynamic pages

An access date is especially important when:

the table updates automatically;
new games are added frequently;
the page does not expose historical editions;
the displayed rating can change without the URL changing;
an event is still in progress.

A suitable form is:

Accessed 28 July 2026.

For a live table:

Accessed 28 July 2026, 14:30 CEST.

Access dates should not replace publication dates when both are available.

A strong citation contains both:

Updated 26 July 2026; accessed 28 July 2026.

21. Preserve a frozen snapshot when possible

A mutable rating page creates a reproducibility problem. A reader following the citation months later may see a different value.

Several preservation methods are possible:

official project archive;
dated downloadable table;
downloadable CSV or text edition;
PDF snapshot;
repository release;
institutional archive;
web archive;
checksum-identified export.

A locally saved screenshot is weak evidence if it is not publicly accessible or independently verifiable. A downloadable table with a stable filename and checksum is stronger.

When a snapshot is created by the citing author rather than the publisher, this should be disclosed:

Author-preserved snapshot of the table as accessed on 28 July 2026.

The author should not silently present a private copy as an official archived edition.

22. Cite the underlying PGN dataset when the claim depends on games

A rating table is a calculated surface. Some claims require access to the underlying game evidence.

Examples include:

recalculating the ratings;
analysing opening distribution;
checking colour balance;
testing incident exclusions;
verifying game count;
reproducing a specific engine-to-engine score;
comparing rating tools.

In those cases, cite the PGN dataset or downloadable event pack separately.

A PGN citation should include:

project;
event or database title;
date or version;
game count;
publication status;
file format;
stable location;
checksum when available;
access date.

A model citation might be:

IJCCRL. [Event name] Final Audited PGN Pack. Version or publication date, N accepted games, PGN format, SHA-256 checksum, accessed 28 July 2026.

When the pack also includes results.json, scheduler_state.json, audit output and a manifest, those artifacts should be named when they are material to the verification.

The current IJCCRL audit framework explicitly treats publication artifacts as part of the evidence layer connecting games, results, scheduler state, audits and final publication.

23. Cite the rating software separately when reproducing the calculation

If the article recalculates ratings, the rating software is another citable research object.

A reproducible calculation should record:

program name;
exact version or commit;
author or project;
source repository;
compilation environment when relevant;
command-line parameters;
input dataset;
exclusions;
output date.

For example:

Ratings were recalculated with Ordo [exact version or commit], using the published PGN corpus and the declared anchoring and White-advantage parameters.

or:

Ratings were estimated with BayesElo [exact version], using the published PGN and the documented command sequence.

The exact version matters because software behaviour can change. This is consistent with the software-citation principle of specificity: citations should allow readers to identify the version, revision or platform variant actually used.

24. A compact citation template

For ordinary technical writing, the following structure is sufficient:

Project. Table or track. Engine identity. Rating and uncertainty, game count. Calculation or publication date. Stable source. Access date.

Example with placeholders:

Computer Chess Rating Lists. CCRL 40/15 Rating List — All Engines. Engine A 4.2 64-bit 4CPU, 3512 +11/−10, 1,840 games. Updated 26 July 2026. Accessed 28 July 2026.

The surrounding sentence should still qualify the claim:

Under the published CCRL 40/15 testing conditions, Engine A 4.2 held a central estimate of 3512 in the edition updated on 26 July 2026.

25. An expanded technical template

For a scientific report, audit or engine comparison, use:

Corporate author or project. Exact table title. Edition, snapshot or calculation date. Engine name and exact configuration. Rating estimate. Uncertainty measure. Number of games. Time control. Hardware or resource class. Opening and tablebase conditions where material. Rating method and anchor. Stable table location. Method-page location. Access date and time.

This form supports reconstruction of the claim without forcing the reader to infer missing variables.

26. Template for an aggregated family rating

When the list combines versions:

Project. Exact global or family table. Engine family. Aggregation policy. Rating and uncertainty. Games or database scope. Calculation date. Rating method. Stable source. Access date.

Example:

TCEC. Official Global Ratings. Engine A family, all versions aggregated under the published global-rating policy, Ordo calculation, rating X as displayed on the dated snapshot, accessed 28 July 2026.

The phrase “all versions aggregated” prevents the citation from being mistaken for an exact-release benchmark.

27. Template for a provisional IJCCRL rating

IJCCRL. Exact time-control and track surface. Exact engine version. Provisional rating and uncertainty where published. Accepted game count. Evidence cutoff. Method and base. Audit status. Access date.

Example:

IJCCRL. Bullet Rating List — Original UCI Track. Engine A version 2.0, provisional rating X after N accepted games, Ordo-based scale with the published reference base, evidence cutoff 26 July 2026, audit status provisional, accessed 28 July 2026.

The current IJCCRL Original UCI Bullet surface demonstrates why corpus size, games per engine, mirror integrity, rating base and knockout exclusions should remain visible near the rating claim.

28. Template for a historical citation

Historical citations should preserve the edition rather than linking only to the current table:

Project. Historical rating-list edition. Date. Engine identity. Rating, uncertainty and games. Archived or downloadable source. Access date.

Example:

Swedish Chess Computer Association. SSDF Rating List, 2023-12-31. Stockfish 16 x64 on the stated hardware, rating 3582, +50/−48, 200 games. Historical table accessed 28 July 2026.

This format follows the source’s own insistence that rating, games and error margin be quoted together.

29. Worked example: correcting an incomplete claim

Consider this first draft:

Stockfish is rated 3650 and is therefore the strongest chess engine.

The problems are substantial:

no rating project;
no table;
no date;
no version;
no hardware;
no game count;
no uncertainty;
no pool;
no distinction between central estimate and universal strength;
no source.

A better version is:

In the dated CCRL 40/15 table, Stockfish [exact listed version and configuration] had a published central estimate of 3650 under CCRL’s stated 40/15 testing conditions. The entry was based on N games and carried the uncertainty reported in that edition.

A stronger interpretation is:

This value identifies the engine’s position within the CCRL 40/15 pool and conditions at that calculation date; it should not be treated as a universal Elo transferable to unrelated rating lists or hardware environments.

The revised claim is narrower, but it is also more defensible.

30. Worked example: a narrow Elo difference

Initial claim:

Engine A is stronger than Engine B because it is three Elo points higher.

Suppose the table reports:

Engine A: 3503 ± 12;
Engine B: 3500 ± 11.

A responsible version is:

Engine A had a central estimate three points above Engine B in the dated table, but the difference was small relative to the reported uncertainty. The publication therefore supports describing the entries as statistically close within that testing environment rather than asserting a decisive strength difference.

Correct citation prevents the ranking order from being exaggerated into a causal or universal conclusion.

31. Worked example: tournament winner versus rating leader

Initial claim:

Engine A won the final, proving that it is the highest-rated engine.

The final result establishes the champion of that match. It does not automatically establish the highest long-term rating.

A corrected version is:

Engine A won the final by the published match score. The result establishes the event title, while the long-term rating order remains a separate calculation based on the relevant rating corpus.

The final should be cited through the event record, Winners page or audit pack. The rating claim should be cited through the rating list.

This separation is central to the IJCCRL publication system:

Events describes what is being played;
Live displays the active competition;
Winners identifies the champion;
Downloads preserves evidence;
Archive records the closed event;
Rating Lists carries the Elo surface;
Rules & Audit explains the method.

The IJCCRL Archive explicitly defines itself as a closed-event index rather than a duplicate rating table or download inventory.

32. Common citation errors

“According to online ratings…”

This does not identify a source.

Citing only the engine family

A family name may conceal multiple versions, networks and configurations.

Omitting the date

The current page may no longer show the cited value.

Reporting rank without rating uncertainty

Rank can overstate differences between statistically close entries.

Reporting Elo without games

The reader cannot assess sample maturity.

Treating a family aggregate as an exact-version rating

This assigns the wrong measurement to the wrong software object.

Mixing rating lists

Numbers from independently normalised lists cannot be combined casually.

Using a tournament score as long-term Elo

A competition result and a rating estimate answer different questions.

Citing only a screenshot

A screenshot without a public source, date and preserved context is weak evidence.

Calling the value “true Elo”

A list-specific estimate is not a context-free intrinsic constant.

Omitting provisional status

A live estimate can be mistaken for a closed publication.

Removing negative information

Crashes, missing games, excluded results, network changes and recalculations may define the limits of the claim.

33. Observation, calculation and interpretation

A strong editorial record separates three layers.

Observation

A game result, engine configuration, clock setting or incident.

Calculation

The rating-tool output derived from an explicitly defined dataset.

Interpretation

The sentence written for readers.

For example:

Observation: Engine A scored 54.2% across 800 accepted games.
Calculation: Ordo estimated a rating of X with interval Y.
Interpretation: Engine A occupied the upper region of the dated table under the published conditions.

A correction to the PGN can alter the calculation. A change in wording may alter only the interpretation. Preserving these layers makes later review substantially easier.

34. Descriptive and causal claims must be separated

A rating table can show that one engine or configuration scored differently from another. It cannot, by itself, prove why.

Suppose Engine A gained 18 Elo after a new release. The table does not establish whether the improvement was caused by:

search changes;
evaluation changes;
a new network;
hardware interaction;
opening distribution;
opponent-pool changes;
statistical fluctuation;
rating-scale movement.

A causal claim requires a controlled experiment designed to isolate the proposed cause.

The rating-list citation supports the descriptive statement:

Version 2.0 had a higher central estimate than version 1.9 in the dated table.

It does not independently support:

The new pruning algorithm caused an 18-Elo improvement.

That second statement needs development tests, SPRT evidence, controlled matches or another appropriate experiment.

35. Minimum evidence statement for publication

Before publishing a rating-centred claim, the editor should be able to complete this statement:

This claim refers to [project], [exact table], calculated or published on [date], using [method], for [exact engine identity], rated [value and uncertainty] after [game count] games under [time control and relevant conditions], with publication status [provisional/final/historical].

If one of those fields cannot be recovered, the conclusion should be narrowed.

Missing information should not be filled from memory.

36. Editorial review procedure

A responsible review can be completed in five stages.

Stage 1: Open the numerical surface

Confirm the exact engine entry, value, uncertainty, game count and date.

Stage 2: Open the methodology

Confirm time control, hardware policy, rating tool, scale, opening rules and incident policy.

Stage 3: Check the engine identity

Confirm version, architecture, threads, network and family-aggregation policy.

Stage 4: Follow the evidence

Where material, inspect the event record, PGN package, audit output or historical archive.

Stage 5: Test the wording

Ask:

Does the sentence say more than the source proves?
Is provisional evidence labelled?
Is the rating list-specific?
Could the page change tomorrow?
Can another reader recover the same evidence?
Is the engine version unambiguous?
Is uncertainty represented honestly?
Is tournament performance being confused with rating?

If the answer to any question is unsatisfactory, revise the claim before publication.

37. Reader checklist

Before accepting a cited chess engine rating, verify:

Is the rating project named?
Is the exact table or track identified?
Is the calculation or publication date given?
Is the exact engine version visible?
Are architecture, CPU/GPU or network details preserved where relevant?
Is the central rating copied accurately?
Is uncertainty included?
Is the game count included?
Is the time control stated?
Is the hardware or resource class described?
Is the opening policy recoverable?
Are tablebase and adjudication conditions available?
Is the rating method named?
Is the scale or anchor explained?
Is the opponent pool identifiable?
Is provisional status visible?
Is the exact table linked rather than only the homepage?
Is an access date included for a dynamic page?
Is a frozen snapshot available?
Can the underlying PGN or event evidence be recovered when necessary?

A citation satisfying these questions is substantially stronger than a bare Elo quotation.

Frequently asked questions

Is the project homepage enough?

It is better than no citation, but the exact table or archived edition is stronger. The homepage may not preserve the numerical state used by the article.

Should I cite rank or Elo?

Cite the quantity relevant to the claim. If discussing table position, rank may be appropriate. If comparing strength estimates, rating and uncertainty are more informative. In many cases both should be reported.

Should uncertainty always be printed?

It should be included whenever available, especially in technical writing or when the argument depends on a small rating difference.

What happens when the page changes continuously?

Record the calculation date and access time, and use a frozen snapshot or dated export whenever possible.

Can I call the number the engine’s true Elo?

No. Describe it as the engine’s rating on the named list under the published conditions.

Can ratings from CCRL, SSDF, TCEC and IJCCRL be compared directly?

Not as though they shared one universal scale. Their pools, dates, hardware, methods, version policies and normalisation rules may differ.

Should I cite the engine developer?

Credit the developer when discussing or citing the software itself. The rating project remains the author or publisher of the rating table.

What if the list aggregates all versions?

State that the value is a family-level aggregate. Do not assign it to a particular version.

Is the game count more important than the rating?

They answer different questions. The rating is the estimate; the game count helps readers judge its maturity. Both should normally be reported.

Should I cite the PGN as well?

Yes when the claim depends on game-level verification, recalculation, opening analysis, audit or reproducibility.

Should Ordo or BayesElo be cited?

Yes when the article reproduces or independently calculates ratings. Record the exact version or commit and relevant parameters.

Conclusion

A correct chess engine rating-list citation does more than attach a source to an Elo number. It preserves the identity of the measurement.

The minimum responsible record contains:

the rating project;
the exact table, track or time control;
the calculation or publication date;
the precise engine version and configuration;
the rating estimate;
its reported uncertainty;
the number of games;
the relevant testing conditions;
the rating method or method page;
a stable source;
the access date.

Additional information becomes necessary when the claim depends on hardware, neural-network identity, opening design, family aggregation, tablebases, adjudication, incident exclusions or scale normalisation.

The central editorial rule is restraint. Quote only what the evidence supports. A table can establish a published estimate within a defined population and testing environment. It cannot convert that estimate into a timeless, universal property of the engine.

Correct citation makes the claim narrower, but also stronger. It allows readers to reconstruct the publication context, examine the uncertainty, distinguish tournament success from long-term rating and follow the evidence from the table to the rules, games, audit records and historical archive.

That is the standard required when chess engine ratings are treated not as decorative numbers, but as public technical evidence.

Sources and technical references

Computer Chess Rating Lists. “CCRL 40/15 — About and Testing Conditions.” Defines the project, time-control equivalence, tablebases, pondering, hash, tournament formats and opening-book conditions. Accessed 28 July 2026.
Swedish Chess Computer Association. “The SSDF Rating List, 2023-12-31.” Publishes ratings, positive and negative error margins and game counts, and expressly asks that these elements be quoted together. Accessed 28 July 2026.
Top Chess Engine Championship. “TCEC Archive and Rating Documentation.” Describes the global Ordo calculation, family-level version aggregation and result-exclusion policy. Accessed 28 July 2026.
Coulom, Rémi. “Bayesian Elo Rating.” Official BayesElo documentation describing the estimation of Elo ratings from PGN game records. Accessed 28 July 2026.
Ballicora, Miguel A. “Ordo: Ratings for Chess and Other Games.” Official source repository and methodological description. Accessed 28 July 2026.
FORCE11 Software Citation Working Group. “Software Citation Principles.” Guidance on credit, unique identification, persistence, accessibility and version specificity. Accessed 28 July 2026.
IJCCRL. “Ratings Lists.” Canonical rating hub defining the two-track structure, time-control separation, publication status and sample-maturity rules. Accessed 28 July 2026.
IJCCRL. “Rules and Audit.” Public rules framework covering tournament conditions, mirrored pairs, UCI configuration authority, incidents, audit requirements and publication artifacts. Accessed 28 July 2026.
IJCCRL. “Archive.” Historical publication surface separating closed-event identity from Downloads and Rating Lists. Accessed 28 July 2026.

Jorge Ruiz Centelles

Filólogo y amante de la antropología social africana

SÍGUEME