Methodology
Where the schema comes from, how each claim is checked against Voyage, and what the automated checks do not cover.
Current figures
| Voyage Beta | 2.52.0 |
|---|---|
| Schema version | V37 |
| Last verified | 2026-10-24 (build CEQ-35sClIFs1VGxwFjh6) |
| Refresh cadence | Every Voyage patch |
| Mutated worlds compared per refresh | 1,838 |
| Trigger clauses compared per refresh | 83 |
| Disagreements with Voyage's validator | 0 |
| Automated tests | 1,681 |
| Engine rules inventoried | 58 invariant rules, 94 error codes, 79 size limits, 34 reference rules |
| Sections documented | 53 |
| Sections settled by hand | narrativeEvents, locations, unassignedAreas |
Where the schema comes from
Voyage ships its editor as JavaScript, and the world schema lives inside it in two forms: a codec describing a saved game state, and an authoring contract describing the fields the editor exposes. Both are read out of the running application on every patch rather than transcribed by hand, which is why the field names, types, allowed values and required fields here match what Voyage accepts rather than what anyone remembers it accepting.
The same pass collects the reference rules between sections, the invariant rules the engine enforces, its error catalogue, the migrations it applies to older worlds, and the default world a new game starts from.
A patch that changes any of this causes the refresh to fail rather than pass quietly, so the wiki cannot drift onto a stale copy of the schema without someone being told.
How the size limits are found
Voyage publishes no list of its caps. Each one is measured against the engine, including how that particular field is counted, rather than transcribed from anywhere. A cap that moves between patches surfaces as a failure on the next refresh instead of as stale documentation. Every figure in Size Limits comes from that pass.
How claims are checked
A refresh is the full run against the live Voyage build: reading the schema out of the application, re-deriving everything from it, and re-checking the result. It happens on every Voyage patch. Two independent things run as part of it.
A differential test against Voyage's own validator. A synthetic world is built from the schema, and every field in it is then mutated in turn and put through Voyage's own decoder, invariant checks and size limits, and through this site's validator. The two verdicts are compared.
A disagreement in either direction fails the build. An error Voyage raises that this site stays silent about would let a broken world reach a player; an error this site raises that Voyage does not would send an author chasing a problem that is not there. Both are treated as defects.
This project's own test suite, covering the validator's rules, the world migration pipeline, the trigger grammar, the builder, and the wiki content itself.
The two counts above measure different things, and neither contains the other. The mutated worlds are judged by Voyage's engine; the tests are run against this site's own code.
What is trusted, and in what order
- Voyage's own code. The codec, the authoring contract and the engine's rules outrank everything else.
- Observed behaviour. Where the code cannot answer a question, the question is put to the running engine, or tested by hand in Studio.
- Voyage's own words. Studio's field descriptions, patch notes, and developer statements.
A claim about how something behaves that rests only on the third tier is tested before it ships, or it does not ship.
What the automated checks do not cover
The differential test builds a synthetic entry for each section. A few sections cannot be given one the engine will accept, because their validity depends on other parts of the world; which ones is listed under Current figures above, since it changes as Voyage does. Their fields are settled against the same engine by hand instead, so those findings rest on the same authority as the automated ones, but they are not re-checked on every patch the way the rest is.
Beyond that:
- The per-turn budget for how many trigger conditions the engine evaluates in natural language is a figure given by a developer, not one read out of the engine.
- Descriptions that Voyage itself provides are checked against the codec or the engine before anything here repeats them.
- Reference documentation from World-Puppeteer is used only where nothing above covers a point, and has been corrected here where the extraction disagreed with it.
- The explanations are written by a person and by AI working from the extracted data. A field is only documented if it exists in the extraction, but the prose around it is a separate layer written on top and can be wrong even where the structure beneath it is right.
- The extraction is not infallible either. A change in how Voyage builds its editor can leave it capturing less than it did, which has happened, so the refresh compares what it found against what it found last time and stops on an unexplained loss.
The tooling that performs the extraction and the differential test is not published. What it produces is: the schema, the validator, and every field description on this site.
Found something wrong?
Corrections are wanted, and past ones from readers are already in here. Tag me on Discord.