Validation

A story-driven game fails in quiet ways: a choice that targets a deleted node, a flag set that nothing ever reads, a quest whose completion condition can never fire, an ending no path reaches. Parlance's position is that these are build errors — findable statically, reportable precisely, and fixable before a playtester ever trips over them.

One validator, three surfaces

The same rule set runs in three places, and they are kept in agreement:

1. On every save. Each write re-runs the full project validation and pushes results over a WebSocket to every open editor window. The validation bar shows live error/warning counts with per-code filters; each issue row navigates to the offending entity. You never refresh, and you never validate "later."
2. In CI. parlance ci-check runs the identical code path headless: exit 1 on errors, --strict to fail on warnings too. See the CI tutorial.
3. Independently. validate.py is a standalone Python reimplementation of the same rules — usable in pipelines with no Node toolchain, and doubling as a second opinion on the rules themselves. A parity test in the main suite asserts both implementations report the same issues, so they can't drift apart silently.

What gets checked

Eighteen check families, spanning shape (SCHEMA), wiring (REF, DUP), flow (FLOW, REACH, GATE), state (FLAG, REP), structure (QUEST, ENDING, COVERAGE, LOC, CUT, LADDER), content (LORE), and progression math (PROG, XP, CHECK). The reference page lists every family with what it scans and how to fix what it finds.

Errors, warnings, and why saves never block

• Errors are broken wiring — a reference to something that doesn't exist, data that violates schema. CI fails on these.
• Warnings are story smells — a dead ladder rung, an unreachable ending, a write-only flag. They're often work in progress, which is exactly why the editor never blocks a save on validation: a half-built quest should be savable, committable, and shareable mid-thought. The discipline point is CI, where --strict draws whatever line your team wants.

Beyond the checklist: Reports

The Reports panel is validation's exploratory twin:

• Coverage & structure — issues grouped by family, clickable through to each entity: characters with no dialogue, unreachable nodes, orphaned flags, endings with no path in.
• The reference index — for any id in the project: where it's defined, every place it's read, every place it's written, each entry one click from the spot. This is "find usages" for your story, and it's what makes renaming or retiring a variable safe. (Variables and items also get an inline Flow panel on their own detail page.)

Validation as a feature of the format

Because the data is schema-first plain JSON with published semantics, deep static analysis is possible at all — you can't statically trace flag flow through a pile of engine-side script. The validator is the payoff of the format's discipline, and via the open spec, third parties can implement the same checks.

Next: wire it into CI in ten minutes · every check family, explained