How We Research

We treat every wiki page as a small claim that has to be defensible. Before something appears in published article text, an editor on our team has to be able to say one of the following four things about it:

1. I read it in the game and I have a screenshot.
2. I tested it in the game and the behaviour reproduces.
3. It is in the official patch notes or developer communication, and I have the link.
4. Multiple independent reproducible sources agree, and the disagreement footprint is small enough to call it consensus.

If none of those four are available, we either rewrite the claim to something we can defend or drop it. "I think I read this somewhere" is not a source.

The strongest source for any claim about a game is the game itself. We start there for almost everything: tooltip text for stats and abilities, in-game books and journals for lore, quest log entries for objectives, NPC dialogue for relationships, and on-screen numerics for damage, cooldowns, and resource costs.

Where the game has its own knowledge base or codex, we treat that as the canonical phrasing. When we paraphrase, we paraphrase carefully and keep an internal note of the exact in-game wording so we can spot drift between patches.

For developer-side primary sources: official forums, developer letters, verified studio social accounts, official press kits, publisher blog posts, and live developer Q&A. We capture these when they are published, because they regularly disappear or get edited later.

A lot of pages on this site contain claims that the in-game UI either does not surface or surfaces incorrectly. Hidden damage modifiers, real cooldown numbers when the tooltip rounds, chest spawn rules, NPC schedule transitions across day boundaries, the difference between "chance to" and "guaranteed on" effects.

For those, we test. Editors run controlled experiments: same loadout across multiple runs, single-variable changes, screenshot before and after, repeat until the variance is small enough to publish. Results that cannot be reproduced are not published as facts. They might appear as "reported but unconfirmed" on a community notes page, with the appropriate hedge.

Live games change. Our patch coverage is on a schedule:

• Same-day: patch notes get a clean summary on the game's wiki within hours of the patch going live, including which articles need review.
• Within 72 hours: critical pages affected by the patch (changed weapons, reworked classes, modified quests, removed exploits) are updated to match the new state.
• Within two weeks: secondary pages that touched on the changed systems are reviewed and either updated or marked for follow-up.

Pages that contain version-sensitive numbers carry a visible patch version when relevant. When a number changes, the old number does not survive in the live article body. It moves to the revision history, which is public, so anyone tracking the change over time can still see it.

Some facts are not visible without datamining: drop tables for chests, internal scaling formulas, hidden affixes, NPC behaviour state machines. We use community datamining where the methodology is public, the tooling is reproducible, and the results are stable across confirmation by multiple independent investigators.

We do not use datamined content that has been published in violation of an embargo or under conditions the developer has explicitly asked the community to respect. When in doubt, we wait until the information is public.

Mainstream coverage (game journalism, video creators, community forums) is useful for context, lead generation, and corroboration. It is not used as a sole source for a factual claim. If a video says a boss has 8,000 HP and the game does not surface the number, we either reproduce the result with our own testing or we do not publish the number.

The body text of our published articles does not name external outlets, domains, or URLs. The research path is internal; the published article should stand on its own. This is a deliberate editorial choice and it is documented in our editorial standards.

We maintain a do-not-cite list internally. A source ends up on it for any of the following reasons:

• Demonstrated history of fabricated game facts.
• AI-generated content published without human review.
• Stat tables that consistently disagree with what the game shows in tooltips.
• Claims that cannot be reproduced when an editor tries to verify them.
• Sites whose ownership or editorial process is opaque enough that we cannot evaluate accuracy.

Inclusion on the list is a per-claim judgement, not a personal attack on the site or its writers. A source can leave the list when its accuracy improves.

Before an article goes live, the assigned editor confirms:

• Every gameplay claim is traceable to a primary source or first-hand testing.
• Patch version is recorded where relevant.
• Quotes from in-game text are exact, not paraphrased silently.
• Stats and numbers match what the game shows, or, where the game does not show them, they have been independently reproduced.
• The article does not duplicate or contradict existing wiki content for the same game without explanation.
• Internal links to related articles are present and point to live pages where those exist.

Articles that fail this checklist do not get published. They sit in drafts until they pass.

The moment an article is live, anyone with an account can read the revision history, see which editor wrote what and when, and submit a correction or an edit themselves. Edits create new revisions; old revisions are not deleted, so the article's history is auditable all the way back.

We monitor for two specific failure modes: large content reductions (which can mean an editor accidentally overwrote good work) and stale patch coverage (which can mean nobody has revisited the page since a system changed). Both feed into our editorial review queue automatically.

If you find a mistake, the fastest path to a fix is the corrections form. It goes straight to an editor, not to a generic inbox.