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 human still reads the prose for 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 they say passed. 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 a certified build. If nobody audits, both files can be valid even though nobody tested the game itself. The experimental certification protocol describes it.

Validation of the files is never proof 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. The package is not valid until it is fixed.
A warning points at something worth a look. It does not make the package invalid.

The authoring tool reports package errors while you write, so missing names and bad data are fixed before a build begins.

Full rules: OpenGDD specification, §2d.