Search for a mechanic in a young game and you usually get one of two things: a confident paragraph copied from a forum thread, or nothing at all. The second result is the harder one to design around, because a blank section and a verified answer look identical from the outside. Readers treat silence as evidence that the mechanic does not exist.
RuneScape: Dragonwilds reached version 1.0 on 15 September 2026, and guides written in the days after a launch inherit a specific problem. The game has more systems than anyone has confirmed yet. The RuneScape: Dragonwilds Guide approaches this as a content-modelling problem, and the patterns it uses are worth borrowing for API references, runbooks, and internal handbooks. The site publishes 22 guides, and every page carries its own source list and verification note at the foot of the article.
Sections that exist to state what is missing
Three of the pages I read end with a section whose whole purpose is to mark the boundary of the page. The builds guide closes with a heading called "What this page will not tell you yet". The performance guide closes with "What this page cannot tell you". The dedicated server guide opens with a "Scope of this page" block that separates the dedicated server player ceiling from the co-op world limit, and adds that cloud hosting documentation was still being written when its sources were published, so provider-specific steps are absent on purpose.
The pattern is cheap to implement and expensive to skip. A documentation page without a scope block accumulates claims until someone notices the contradictions. A page with one tells the reader where to look next, which is the same job a limitations section does in an API reference. Writing it forces the author to decide what the page is actually for.
Claims that carry an evidence class
The performance and controller page shows the second pattern most clearly. It states near the top that no source it used contains an official settings guide. The only first-party guidance it found was two moderator replies in a community thread. Everything more specific came from a single creator's April 2025 optimisation video. It then labels the numbers accordingly, and says that nothing was measured for the page, so every figure is one person's report on their own machine.
That is an evidence class attached to individual claims rather than to the page as a whole. The same page describes one set of reports as "a report, not a benchmark", which is the sentence most documentation teams need somewhere in their style guide. In prose, a reported value and a measured value differ by a sentence. In a content model they should differ by a field, because the distinction survives copy edits only when something checks it.
Unknown is a state, not an empty field
The most useful lesson sits in the records themselves. The guide to the quest Seeking Salvation notes that the wiki revision behind it predates 1.0, and that the article carried no reader comments, so no community correction was available to weigh against the text. The builds page, written the day after launch, describes unlock pacing as an open re-check item rather than a settled figure. Neither statement is a disclaimer bolted on at the end. They are the shape of a claim record with three states instead of two:
{
"claim": "Dedicated server player ceiling",
"status": "verified",
"value": "2 GB RAM + 1 GB per player",
"source": "official documentation",
"checked_at": "2026-09-16",
"applies_from": "1.0"
}
That shape is illustrative, not the site's data. The third state is the part that matters: an unknown is not false. If a schema allows only verified and false, the maintenance path of least resistance is to leave the field empty and let the renderer decide. Empty usually renders as nothing, and nothing reads as "no such mechanic", which is how a wiki starts quietly lying about console clients and dedicated servers that probably do work together, even though the official documentation reviewed by the page does not spell out how.
Staleness belongs per page
Freshness here is not a site-wide banner. Each guide carries its own header line with the date its sources were checked, a citation count, and a statement that the page is an independent fan-made guide. The quest page pins its facts to a version, naming update 0.10 on 15 December 2025 as the release that added the quest and its region. The world settings page does the same for the Custom mode, which it attributes to update 0.9.
That structure makes one automated check easy to propose: at render time, compare the version a claim was verified against with the product's current release, and fail the build or badge the claim when it falls behind. This is a design suggestion on my part rather than something the site does. It is also the kind of check that pays for itself in any product shipping on a weekly cadence, because re-verification is the step that silently stops happening.
What the approach costs
Negative scope and evidence labels add real work. Every unknown section has to be maintained, and the maintenance shows nothing for it until the day it prevents a wrong answer. Hedged prose also reads worse than confident prose, and a page that says "not documented" five times is less pleasant than one that guesses.
The tradeoff is defensible when the audience acts on the information. A player who follows a guess about a boss mechanic wastes an evening. A developer who follows a guessed config value wastes more. The site's answer is to make the boundary of the known explicit, and to attach a reason to each uncertainty so the reader can decide how much weight to give it. Nothing about that mechanism is game-specific.
This article was prepared with AI assistance.
Top comments (1)
"Unknown is a state, not an empty field" applies well beyond game wikis, most API docs and internal runbooks silently treat unverified as false because the schema only has two options. Attaching an evidence class to individual claims instead of hedging the whole page is a much better pattern than the usual all-or-nothing disclaimer.