What validation proves

Three different checks happen between a design and a finished game. Each one proves something different, so a pass means something different each time.

Package checking reads your files: names, links, numbers, rules and the shape of the prose. The validator (the checking tool) does it while you write. A person still reads the prose to check that it makes sense.
Build record checking compares what the builder says they built with what you asked for. The builder is the person, team or AI that turned the package into a game. Their build record is a JSON report: which answers were chosen, the numbers as built, and which tests passed or did not pass. This check does not rerun the tests, and it does not prove the report is true.
Auditing runs the tests and reviews the art direction against the finished game. A separate auditor does it, only when someone asks for an audit of a build. If nobody audits, both files can be valid even though nobody tested the game itself. The experimental certification protocol describes it.

Valid files never prove that the finished game works.

a validator finding, from the command line

ERROR [PROSE_CITATION_DANGLING] 02-mechanics.md:3 — prose citation `stamina.regen` does not resolve to a tuning.json key (SPEC §4)

The name in brackets is the code for the exact rule. Quote it when asking for help.

There are two severities:

An error means the package or the build record breaks a rule of the format. It is not valid until the error is fixed.
A warning points at something you should check. It does not make the package invalid.

Errors and warnings check structure: names, links, numbers, and the shape of files and blocks. They do not read the meaning of your words, so a package is checked the same way in any language.

Hints are optional. The validator gives them only when you ask for review mode, for example with --review on the command line. A hint points at a place you may want to read again. One example is a rule that picks one thing from several, but may not say what happens when two of them are equal. Another is a number in your prose that equals one of your decided numbers in tuning.json. Hints are never errors or warnings, and they never change the result. They only work on English text.

The authoring tool reports package errors while you write, so you can fix missing names and wrong data before a build begins.

The safety scan#

By default, the report of a package check ends with a separate safety scan. It points out places a person should look at before giving the package to an AI that can run tools, such as a line that tells an AI to ignore previous instructions or to run a command. The safety scan never changes the result. It does not prove that a package is hostile, and it does not prove that a package is safe. Some of its checks only read English, so the scan may not report a hostile instruction in another language.

What a build record check says#

When the validator checks a build record, it gives exactly one result. The exit code is the number the command returns, so a script can read the result.

Conforming: your package has at least one acceptance test, and every test passed. Exit code 0.
Incomplete: at least one test failed, could be run only in part, or did not run. The record lists each one with a reason. Exit code 3.
Not verified: your package has no acceptance tests. Exit code 3.
Invalid: the record has at least one error. Exit code 1.
Not checked: the validator was not given your package, and the record has no errors of its own. The validator could not compare the record with your package. Exit code 3.

Only conforming means the build passed every test in your package. Tests the builder adds on their own do not count.

Full rules: OpenGDD specification, §2d and §7.