Methodology

The data pages show facts. Each release's evidence page (linked from the marks beside its facts) shows the statements the facts were resolved from. This page shows the method: where statements come from, how they are joined to a copy, how a fact is decided when sources disagree, what cannot be checked, and the measures each build takes of its own reliability.

Measured over build 2026.10.09: 115,338 commercial releases, 504,785 release-and-fact cells with evidence.

What a fact is

A fact is a value a source states about a subject: the publisher of a release, its date in a market, its player count. Every statement is kept as it was made, with its source, the kind of join that attached it to the copy, the scope it speaks for (this copy, one market's date, or the title on the platform), where to look it up again, and when the build read it. Nothing is published that is not backed by at least one statement, and a correction is itself a statement (tier 0) with its reason.

Where statements come from

Two tiers above these are designed and partly built: the media itself (headers a publisher wrote into a cartridge or disc, title screens), tier 1; and the press of the day (magazine scans), tier 3. Where they exist they outrank the lists and the web.

How a statement is joined to a copy

An identifier join is exact: a checksum, a serial, a Nintendo game code, an arcade set name. It attaches the source's record to this very copy.

A title join is a guess: the copy's title, folded (case, accents, punctuation and articles removed), looked up in the source. It attaches the source's record for a game of that name on that platform. Its failure mode is a different game, or a different edition, of the same name. A main-title join is a weaker guess still: the part before " - " ("Pokemon - Versione Oro" becomes "Pokemon"), tried only for editions and translated releases, and never allowed to carry identifiers or native titles, because the entry it finds is the base game's or a series'.

Every statement records which join made it, and the measures below are kept per join.

How a fact is decided

1. Statements about the copy itself (identifier joins) are taken before statements about the title.
2. Among those, the highest tier decides.
3. Within a tier, the value more distinct sources state wins; then the value more of the title's other entries state; then confidence; then a fixed source order.
4. A date is decided year first, then the month among statements with that year, then the day, so a month is never attached to another source's year. A date more than a year before the platform launched, or later than the build's own year, is not a release date and does not vote (the statement stays).
5. A company name that stands for a group ("Sega", "Nintendo", "Electronic Arts") beside one that names the arm or label ("Sega of America", "Nintendo EAD", "EA Sports") is not a disagreement: the group's statements count for the arm, and the arm is published.
6. A hand-kept correction wins over every source and records its reason.

What is not done: a value is never invented, averaged or interpolated; an empty field means no source stated a value that passed the rules.

What cannot be checked

There is no registry of video games to check against. The dump lists are the nearest thing to a primary source for what was sold where, and the media stage will read the cartridge and the disc themselves; but publisher, developer, genre and player counts rest, for most releases, on databases that people typed in. Two things follow.

First, agreement between sources is the only measure of accuracy available before a sample is checked by hand. The literature on truth discovery (Li and others, 2016; Zheng and others, 2017) estimates each source's reliability from how often it agrees with the others on the facts several sources cover, then uses that reliability to weigh the facts only one or two sources cover. That is what the measures below do.

Second, the sources are not independent. LaunchBox contributors and GameTDB editors read Wikipedia; libretro's facts file was compiled from the same web. Two sources agreeing is therefore less than two independent witnesses, and the copying measure below estimates how much less (Dong, Berti-Equille and Srivastava, 2009: sources that share the same errors share a lineage).

The measures

Every build computes these over its commercial releases and the five facts the web sources decide most (date, publisher, developer, genre, players). They are published here and shipped in the archive as quality.json.

Support behind each published fact

How many distinct sources state the published value, and how often some source states another. "Contested" means at least one source disagrees. The last column is the share backed by at least one source joined to the copy by an identifier.

Published on one source alone, by source: date wikipedia 10,217, gametdb 5,677, launchbox 4,786, libretro 2,579, mame-sl 1,572; publisher wikipedia 10,691, launchbox 7,604, libretro 4,584, gametdb 2,878, wikidata 2,646; developer wikipedia 13,139, launchbox 11,850, libretro 6,960, gametdb 2,607, wikidata 2,346; genre libretro 13,469, launchbox 12,756, wikipedia 10,523, wikidata 9,695, gametdb 6,961; players launchbox 30,314, gametdb 10,774, libretro 5,885, mame 3,556, wikidata 440.

Agreement between pairs of sources

Where two sources both state a value for the same release and fact, how often they state the same one. Genre agreement is low because genre is a taxonomy, not a fact: "action" against "action-adventure" against "platformer" is a difference of vocabulary more than of knowledge, and agreement at the top level of the genre tree is about twice as high as at the full id.

Reliability per source, estimated without a reference

For each source, field and kind of join: among the cells where at least two other sources agree with each other, how often this source states what they state (leave-one-out agreement). The second estimate is from an iterated weighted vote (Li and others, 2014, "CRH"): every source starts equal, the vote picks a value per cell, each source's error rate is how often it was outvoted, the weights are recomputed from the error rates, and so on for ten rounds. A source joined by identifier is measured apart from the same source joined by title.

Copying between sources

Among the cells where a source joined by identifier states a value and two title-joined sources both contradict it, how often the two contradict it with the same value. Independent sources rarely make the same mistake; a high share means one copies the other, and their agreement counts as one voice.

Title joins against identifier joins

For dates: how far a title-joined statement's year is from the year an identifier-joined source gives the same release. A gap of three or more years is almost always a different edition or a different game of the same name.

Where an agreement rule would differ from the tier rule

The published values follow the tier rule above. This counts how often the weighted vote, which trusts each source by its measured reliability instead of its tier, would settle on another value. The difference is where a hand check decides which rule is right; until then the tier rule stands, because it is the one a reader can follow by eye.

Reading the marks beside a fact

On a release page each fact carries a mark: "3 sources agree" (green when at least two sources agree and one of them was joined by an identifier), "2 agree · 1 differs" (amber: contested), "one source" (grey: nothing confirms it, nothing contradicts it), and "title match" when no identifier join backs the value. The mark links to the evidence page, where every statement is listed with whether it agrees with what was published. The same numbers ship in the release's JSON under support.

A fact with one source is not wrong; it is unconfirmed. The reliability tables above say how often that source, joined that way, agrees with the others where they can be compared, which is the best available estimate of how often it is right on its own.

Known weaknesses

• Most publisher, developer, genre and player values come from title joins to user-edited databases. The support table says how many stand on one source.
• Wikidata's date is a game's first release anywhere, not this release's date; it is used only when nothing release-scoped exists, and the release page says so.
• Company names differ between sources more by convention than by fact (a group, an arm, a label, an old name). The build folds spellings and legal forms, maps known aliases, and treats a group name as compatible with its arm; what remains in the publisher and developer disagreement is largely this.
• Genre is a controlled list (about a hundred ids in a two-level tree) with a mapping from each source's words; the mapping is a judgement and is published with the archive.
• Lists include announced games; a date after the build's year is held back, but a wrong early date is not caught.

What is planned

• A hand-checked sample each build, stratified by how many sources back a fact and by platform family, with confidence intervals on the error rate per stratum (Wilson intervals; about four hundred facts for five points of precision). The sample calibrates the reliability estimates and decides between the tier rule and the weighted vote where they differ.
• A confidence per fact from the measured reliabilities (the log-odds sum of Dong and others, 2009), published as a probability band beside the mark.
• Media and press tiers at scale, so that date, publisher and title rest on the cartridge, the disc and the magazine of the day rather than on the web.
• A completeness estimate per platform from the overlap between independent lists (capture-recapture), with its assumptions stated.

Corrections

A wrong fact is reported as an issue naming the release id and the right value with where it can be checked. Accepted corrections become overrides in the build (tier 0), each with its reason, and every build's QA report lists them. A correction never deletes the statements it overrules; they stay on the evidence page.

Reading

• Li, Gao, Meng, Li, Su, Zhao, Fan, Han. "A Survey on Truth Discovery." SIGKDD Explorations, 2016.
• Zheng, Li, Li, Shan, Cheng. "Truth Inference in Crowdsourcing: Is the Problem Solved?" PVLDB 10(5), 2017.
• Li, Li, Gao, Su, Zhao, Fan, Han. "Resolving Conflicts in Heterogeneous Data by Truth Discovery and Source Reliability Estimation." SIGMOD, 2014.
• Dong, Berti-Equille, Srivastava. "Integrating Conflicting Data: The Role of Source Dependence." PVLDB, 2009.
• Li, Dong, Lyons, Meng, Srivastava. "Truth Finding on the Deep Web: Is the Problem Solved?" PVLDB 6(2), 2013.
• Dong and others. "Knowledge Vault: A Web-Scale Approach to Probabilistic Knowledge Fusion." KDD, 2014.
• Klie, Castilho, Gurevych. "On Efficient and Statistical Quality Estimation for Data Annotation." ACL, 2024.
• Chu, Ilyas, Krishnan, Wang. "Data Cleaning: Overview and Emerging Challenges." SIGMOD, 2016.
• GBIF. "Occurrence issues and flags." Technical documentation.