A Practical Content Model for Versioned Game Guides

Documentation for a live or Early Access game behaves more like versioned software documentation than a traditional magazine article. Mechanics change, official wording evolves, and community discoveries arrive before they can be reproduced. If a guide stores all of that as undifferentiated prose, maintenance becomes guesswork.

While building an independent Fatal Frontier 1869 guide, I adopted a small content model that separates the claim, its evidence, and its lifespan.

Start with the claim, not the page

A page is a presentation. The maintainable unit is the claim behind it. For each update-sensitive statement, record:

type EvidenceState = "official" | "observed" | "reported" | "unknown";

type GuideClaim = {
  statement: string;
  state: EvidenceState;
  sourceUrl?: string;
  checkedAt?: string;
  checkedBuild?: string;
  reviewTrigger?: "patch" | "terms-change" | "manual";
};

This is a conceptual model rather than a required stack. It works in a CMS, Markdown front matter, JSON, or a relational database. The important part is that evidence state is explicit.

Give unknowns a first-class state

Many content systems allow published or draft, but not “the question is valid and the answer is unknown.” That gap encourages accidental fabrication.

An unknown record lets the public page say exactly what is missing. It also creates a useful research queue: look for an official source, reproduce the behavior, or keep the answer marked as unresolved.

Attach review triggers

Dates alone do not explain why a statement should be checked again. I use review triggers:

• patch for mechanics and numeric values;
• terms-change for eligibility, purchases, withdrawals, or other real-value rules;
• manual for durable explanations that change only when the whole system is redesigned.

This reduces unnecessary rewrites. A new patch can invalidate a movement threshold while leaving the first-run decision framework intact.

Render evidence close to the answer

A source list at the bottom is useful, but it does not show which citation supports which sentence. The page should place a small evidence label, date, or source link near a volatile claim. The interface can stay quiet; the relationship just has to remain visible.

For search pages, I still lead with a concise answer. The evidence and limitations follow immediately, so a search snippet or AI extraction is less likely to detach a number from its conditions.

Organize routes by intent

The navigation should reflect real tasks rather than the internal database:

• first expedition;
• supplies and survival;
• Pioneers and game systems;
• extraction;
• gold, costs, and current official rules;
• evidence and update status.

One claim may appear in several routes. Keeping it structured makes those appearances consistent while allowing each page to explain the decision in its own context.

A concrete example

The approach is visible in the independent Fatal Frontier 1869 Wiki. The site covers beginner routes and systems while keeping official statements, repeatable observations, player reports, and unresolved details distinct. It is an unofficial project and is not affiliated with the game's developer.

The broader pattern applies to any fast-moving knowledge base: store certainty and freshness with the content, render them near the answer, and let update events target the smallest affected unit. That turns maintenance from a full-site rewrite into a bounded review.