Warhammer Survivors Editorial Standards and Ranking Method

What do the evidence labels mean?

Every factual block should tell a reader what kind of evidence it contains. Official means a developer, publisher, store, or official game announcement says it. Historical Demo means the fact belongs to a dated Demo build and is not silently carried into the full game. Community lead means a player discussion can guide research but has not been independently checked. Observed release means a recorded full-game observation includes its build, platform, date, and reasoning.

Original informational diagram, not gameplay footage: it explains the evidence labels rather than presenting gameplay results.

This policy is why the evolution chart puts community ingredient pairs in a separate historical research table. It is also why the characters roster preserves the two Lyssa spellings and Yarrick source wording instead of silently rewriting them.

For concrete primary-source examples, compare the official Steam app metadata with the official Steam launch announcement. A store field can establish product scope, while an announcement can establish a dated release or Demo rule; neither one automatically proves a gameplay ranking.

What does a fair future ranking require?

A release-build tier verdict should compare like with like. Set the game build and platform first, record the universe and stage where relevant, and keep the upgrade context comparable. Then observe survival consistency, crowd control and reach, setup requirements, and any evolution or companion relationship that the run actually demonstrates. The point is not to turn one exciting run into a universal grade.

Repeat the comparison enough to explain the trade-offs. Record the hero, starting conditions, item names, trigger or result, observation date, and source. If a mechanic is unknown, label it unknown. If a result changes after a patch, update the affected record and retain the old scope. The homepage’s pre-release tier-list answer links to this method, so future results can be explained without pretending the test has already happened.

Original informational diagram, not gameplay footage: it describes the future test protocol, not a completed ranking.

What fields belong in a source record?

Use a small, inspectable record for every claim:

• Claim: the exact statement being made.
• Source: URL, publisher, or recorded observation.
• Build and platform: Demo date or release version, plus platform.
• Observation date: when the source or run was checked.
• Certainty: official, historical Demo, community lead, or observed release.
• Reasoning: what the evidence supports and what it leaves open.
• Correction path: where a reader can challenge the claim and what will be rechecked.

The release-date guide uses this approach for platform scope and Demo progress. The mobile guide uses it to keep announced launch platforms separate from unconfirmed device and connectivity details. A missing field is a reason to narrow the wording, not a reason to invent a value.

How are corrections handled?

When a source changes or a reader disputes a fact, identify the page and exact claim, attach the new primary source or build record, and check whether the change affects related pages. Resolve spelling conflicts explicitly instead of creating duplicate entities. Update the date and scope beside the claim, and keep historical Demo wording when it remains useful context.

Original informational diagram, not gameplay footage: it shows how a correction changes one record while preserving its history.

No current page should claim a hands-on release tier, complete recipe list, unlock tracker, or player-tested build recommendation. The wiki hub lists the source-backed pages that are ready now. When the November 10 release arrives, these standards give the site a concrete way to decide which records are ready for publication and which still need another check.