Fact-Checking Policy

What we check, how we check it, the sources we trust, and what happens when we get something wrong.

Last updated 1 September 2026

What we fact-check

Most of what we publish is verifiable by doing: if a page says a gem is worth 25 points or a shield absorbs one hit, that is checked against the game itself. The claims that need external verification fall into four groups:

Browser technology. Canvas behaviour, storage limits, audio policies, input events, the Web Share API.
Web standards and accessibility. WCAG requirements, reduced-motion behaviour, focus handling.
Performance. Core Web Vitals definitions and thresholds.
Game design claims. Anything presented as a general principle rather than as our own practice.

Our verification process

Identify the claims. Before publication, every factual assertion in a draft is marked.
Test what can be tested. Anything about our own games is verified by playing them and reading the code.
Source what cannot. External claims are checked against primary documentation, and the article links to it.
Cut what cannot be supported. If a claim survives neither test, it is removed or rewritten as an opinion clearly marked as ours.
Re-check on update. When a page is revised, its factual claims are re-checked rather than assumed to still hold.

Sources we rely on

For technical subjects we prefer primary documentation over secondary commentary:

We never invent a citation. If you find a link on this site that does not support the sentence it is attached to, that is a bug and we want to hear about it.

Our no-fabrication rule

We do not publish invented statistics, invented studies, invented expert quotes, invented user testimonials, invented player numbers or invented ratings. This is the rule we are least willing to bend, because a single fabricated number undermines every honest sentence around it.

It has a practical consequence you will notice: our articles often describe a mechanism without quantifying how common it is. That is deliberate. A concept explained clearly without a number is more useful than a number we made up.

How corrections are handled

If we get something wrong, email editorial@gemarcadegames.xyz with the page and the sentence. Then:

We check the claim ourselves, usually the same week.
If it is wrong, we fix it and move the page’s last-updated date.
If the error was substantive — a wrong value, a wrong rule, a wrong technical claim — we add a short correction note to the page rather than changing it silently.
Typos, broken links and formatting are fixed without a note.
We reply to whoever reported it.

Keeping game pages accurate

Game pages describe live software, so they can drift out of date in a way an essay cannot. When a game’s tuning changes — a jump height, a gem value, a difficulty tier, a control — its page is updated in the same change, because the page content and the game metadata are generated from the same source file.