Designing Version-Aware Game Reference Data Without False Freshness

Game reference sites have a quiet data-modeling problem: the current game version is not the same thing as the version of every dataset on the site. Showing one global "updated" badge can make old recipe, quest, or balance data look current when only the homepage or patch summary was refreshed.

Model provenance at the dataset level

A safer model gives every collection its own status fields:

type DataStatus = {
  liveGameVersion: string;
  checkedVersion: string;
  checkedAt: string;
  source: "game-files" | "official-note" | "manual-test";
  limitations: string[];
};

The UI can then display the live release globally while keeping recipe, raid, trade, and quest boundaries local. A new patch changes liveGameVersion; it does not automatically rewrite checkedVersion for every collection.

Keep extracted facts separate from interpretation

Structured values and editorial guidance should not share one undifferentiated field. Crop values, raid thresholds, and bot budgets can be extracted facts. Advice such as "grow only what you can protect" is interpretation. Keeping both useful while labeling their source makes future audits much easier.

Expose edge cases as tests

Reference tools should publish the boundary conditions that drive their calculators. For a raid model, that includes zero-value crops, exact threshold edges, multiplayer caps, and whether opening groups are applied before weighted reinforcement selection.

A small test table is often more valuable than a generic accuracy claim:

const cases = [
  { cropValue: 0, expectedLevel: 0 },
  { cropValue: 1, expectedLevel: 1 },
  { cropValue: 10000, expectedLevel: 6 },
  { cropValue: 10001, expectedLevel: 7 },
];

The version-aware Scrap Mechanic reference is a useful live example. It shows the current game as 1.0.5 while warning that individual recipes, trades, unlocks, and raid tables keep their own labels until they are reprocessed or retested.

Design the page around verification

Each data page should answer four questions:

1. What is this value?
2. Where did it come from?
3. Which version was checked?
4. What remains uncertain?

That structure also improves maintenance. When a patch lands, an editor can filter datasets by source and checked version instead of guessing which pages need work.

Do not hide uncertainty

"Current" is not a binary property. A quest route may remain correct while a reward changes. A recipe list may be extracted from one build while schematic unlocks come from a later progression pass. Honest boundaries are more useful than a single green badge.

The broader lesson is that freshness belongs to evidence, not to the domain. If a page makes the evidence visible, readers can decide whether the information is safe to apply to an important save.

This article was prepared with AI assistance and manually checked against the referenced live pages.