Editorial standards and fact checking

Where our information comes from, how it is verified, how unconfirmed claims are labelled, and how versions and corrections are tracked.

Editorial policy and fact-checking standards

Editorial policy

This page sets out where GameStrategists guide content comes from, how it is verified, how unconfirmed material is labelled, and how we correct it when we get it wrong. You can use it to decide whether our content deserves your trust — and to hold us to it.

Last revised: 17 September 2026

1. What we publish, and what we do not

We only publish information that is tied to a specific game build and that a reader can verify independently: puzzle solutions and how the answer is derived, where a clue lives in the game, the trigger for each ending, where a password or keyword comes from, the order of chapters and story beats, and the mistakes we made while building it.
We do not run a generic guide template: everything here covers games we built ourselves, so we are the authors of the thing being documented rather than a third party relaying someone else’s playthrough. Every answer can be checked against the source code and the live build, and changes are recorded in the change log at the foot of each article.

2. Sources, in order of trust

First: the game’s source code and data files. The accepted answers, the other spellings the game accepts, the ending branches and the clue ids are read from the implementation itself (for example `endings.js`, or the submit function for the final puzzle) — never from memory or from guessing at a screenshot.
Second: the live build. We play the currently deployed version start to finish and confirm that the answer is actually accepted and that the ending actually fires. Screenshots in an article come from that run, not from promotional art.
Third: the author’s design notes and devlog. These explain why a puzzle is built the way it is. They are context, not evidence.
Where the two disagree, the live build wins and the change log says so. Every article states which build it was checked against — after a game update, that date is how you judge whether the article still holds.

3. How we handle what we have not confirmed

We do not publish leaks, rumours or datamining as filler. We do not cover other people’s games, and we are not chasing an "early guide" window.
Anything we have not verified ourselves is marked as unverified or left out. A mechanic that is easy to miss — a confrontation that only appears at a particular moment, for instance — is written with its trigger conditions and the basis for the claim, not softened with "reportedly" or "possibly".

4. Version tracking and content updates

Every article carries a publication date and the build it was checked against; when the content changes substantively — an answer changes, an ending condition changes, the game is revised — it also carries an updated date and an entry in the change log at the foot of the article. Typo-only fixes are not marked as revisions.
After a game update, affected articles are revisited: conclusions that still hold are kept, ones that no longer hold are corrected or removed. We do not keep a dead guide on a live URL to protect its traffic — the most recent case was The Last Online, rewritten from "two endings" to three.

5. Corrections

If you find an error, tell us through the contact page and include the page address and the specific claim that is wrong — the more precise, the better (for example “the answer to puzzle 4 in section 3 stopped working after the 19 October revision”).
Once verified we fix the text itself and reflect the change in the updated date. We do not quietly edit without a trace — if the problem you reported was real, the correction stays visible on the page.

6. Our use of automation and AI tools

We say this plainly: guide content on this site uses automation and AI-assisted tools to gather material, structure it and produce first drafts. We would rather disclose that than leave it unstated.
Within that, we hold ourselves to a few lines: no generating pages in bulk that have nothing to do with the game in question; never publishing tool output as “verified” without checking it. Every answer, accepted alternative, ending trigger, clue id and screenshot in an article is checked against the source code and the live build described in section 2 before it goes out.
In other words, a tool’s output is raw material, not a conclusion. You can use the standards on this page to test whether we live up to that.

7. Trademarks and ownership

Our guides cover only the games we ourselves build. We author the code, puzzles and art of every game documented here, so these are first-party guides rather than a third party relaying somebody elses play experience. Third-party product names mentioned elsewhere remain the property of their owners and we are not affiliated with, endorsed by, or sponsored by their makers.
The original ARG puzzle games on this site and the text written for them are copyright GameStrategists. Please credit the source if you quote us. Full terms are in the disclaimer.

Independent ARG game development methodology

/game-methodology

How we design the puzzles and narrative of our original ARG games.

Gaming industry notes

/gaming-insights

What we have observed about guide content and the industry around it.

Disclaimer

/disclaimer

Terms of service

/terms

Contact us

/contact

Corrections, suggestions and collaboration.