Disclosure: I help maintain AzerothSurvivors.app, an independent fan reference for Aethus's game. This article was drafted with AI assistance and checked against the public, version-labelled reference pages. The example below is illustrative, not extracted game code.
A game database can contain hundreds of accurate numbers and still answer the wrong question. A client definition tells you what a field says in a particular build. It does not tell you how often players win with that item, whether a browser release matches a Windows snapshot, or whether a recommended build was tested under equal conditions.
The new Azeroth Survivors item reference makes those boundaries visible. Its October 21 snapshot names Windows client 0.106.0 and separates permanent equipment from jewelry selected during a run. That makes it a useful example for discussing how to publish a small, auditable game reference.
1. Give a snapshot an identity
A label such as "updated today" is not enough. Keep the source platform, client version and check date together. A new website deployment does not necessarily mean that the underlying game data changed.
For a static site, this can be a small manifest stored alongside the records:
{
"game": "Azeroth Survivors",
"platform": "Windows",
"clientVersion": "0.106.0",
"checkedOn": "2026-10-21",
"evidenceKind": "static-client-definitions",
"combatBenchmark": false
}
This is an example schema, not a claim about the site's internal file format. The important part is that the template renders these fields where readers use the numbers, rather than hiding the scope on an About page.
2. Distinguish identities from appearances
The published snapshot records 415 standard equipment identities and 83 PvP identities. It also identifies 83 faction appearance IDs as variants, not another set of stat bonuses. Counting every ID as an additional item would inflate the catalogue without adding a new equipment choice.
A normalized model can represent an equipment identity once and let presentation variants reference it. Likewise, a class name should not be the primary key: names can be translated, corrected or reused. Stable identifiers and explicit relationships are easier to validate than text matching.
3. Validate relationships before rendering
A boss table and an equipment table can each look plausible while disagreeing with each other. A few cheap integrity checks catch that failure before deployment:
- Every drop references a known item and boss.
- An item's class reference resolves to a known class.
- Item IDs are unique within the declared snapshot.
- Numeric chances are in range and carry their unit.
Here is a deliberately small Python example of one check:
from collections.abc import Iterable
def check_drop_references(
drops: Iterable[dict[str, str]],
item_ids: set[str],
boss_ids: set[str],
) -> list[str]:
errors: list[str] = []
for index, row in enumerate(drops):
item_id = row.get("item_id")
boss_id = row.get("boss_id")
if item_id not in item_ids:
errors.append(f"drop[{index}]: unknown item {item_id!r}")
if boss_id not in boss_ids:
errors.append(f"drop[{index}]: unknown boss {boss_id!r}")
return errors
Run this against an immutable snapshot and fail the build when references are broken. A successful test proves that references resolve; it does not prove that the source itself reflects the current live game.
4. Keep units explicit
A perk that adds five percentage points is not the same as a five-percent multiplier. A base value of 20 percent becomes 25 percent in the first case and 21 percent in the second.
Store the base chance, additive modifiers and multipliers as different concepts. Render a worked example next to the rule. Do not collapse all rarity groups into one headline rate or imply that a probability guarantees a drop after a fixed number of attempts.
5. Keep recommendations out of the raw-data layer
An item table describes definitions. A class build guide adds a proposed sequence: permanent talents, in-run spell choices and equipment priorities. A player video is a third kind of evidence, with its own date and conditions.
Those can be linked without being merged into one authority level. Mark a route as a plan, identify an attributed player example, and keep unmeasured comparisons out of a supposedly factual table. A 31-point route is useful even when it does not establish a universal best build.
The practical goal is not to make every field sound certain. It is to let a reader see which snapshot they are consulting, follow an item to its source, and recognize where interpretation begins. That is a better foundation for future updates than a large table with no provenance.
Azeroth Survivors is made by Aethus. The reference site is not affiliated with Aethus or Blizzard Entertainment and does not host or redistribute game files.
Top comments (0)