Valid, invalid, and exactly where
The validator returns one of two verdicts. On a valid string it confirms the input is a member of your language. On an invalid one it reports the furthest position it managed to parse to and what the grammar expected at that point — for example, invalid at position 21, expected "." or " for " but got "x". That's a compiler-style error: not 'this looks wrong somewhere' but 'this broke here, and this is what should have come next'.
Because it's deterministic, the same input always produces the same verdict. That's what makes it safe to act on — you can print it as an editor squiggle, fail a check on it, or surface it to a user, knowing it won't flip between runs the way a model's judgement can.
Why a parser, not the model that wrote it
It's tempting to ask the same LLM 'is this valid?' after it generates. Don't: a model can be confidently wrong, can't reliably name the failing character, and gives different answers on different runs. None of that survives contact with a real workflow where you need to block, annotate, or explain.
A generated parser has none of those weaknesses by construction. It either consumes the whole input according to the grammar or it doesn't, and it knows precisely where it stopped. If your grammar is ambiguous, the validator explores the valid parses and accepts the input if any parse consumes it.
One grammar drives both generation and validation
The same grammar that dsl.ai compiles into a decoding constraint also generates this validator, so generation and checking can't drift apart. Update the grammar and both move together — there's a single source of truth for what 'valid' means. That's especially useful for checking input the model didn't produce: hand-written DSL in a pull request, a config file an engineer edited, a query someone typed. The parser treats all of it the same way, and tells you exactly where any of it breaks.
how it works
- 01
paste your grammar
Bring your DSL's EBNF/GBNF-style grammar into dsl.ai — no training set, no GPU.
- 02
generate the validator
dsl.ai compiles the grammar into a deterministic parser for your language.
- 03
run a string through it
Feed it model output or hand-written DSL and get a valid/invalid verdict.
- 04
read the exact error
On invalid input, see the furthest position reached and what the grammar expected there.
frequently asked
- What does an invalid result actually contain?
- Invalid, plus the furthest position the parser reached and what it expected at that point — for example, invalid at position 14, expected "%" or " for " but got "x". Enough to fix it in seconds.
- Is the validator deterministic?
- Yes. The same input always yields the same verdict, which is why you can safely use it to block a merge, annotate an editor, or show an end user — unlike a model's judgement, which can change between runs.
- Can it check DSL a human wrote, not just model output?
- Yes. The parser validates any string in your language regardless of where it came from — a pull request, a config file, a typed query — and names the exact failure either way.
- What if my grammar is ambiguous?
- The validator explores the valid parses and accepts the input if any parse consumes it, so an ambiguous grammar still gives a sound valid/invalid verdict.
Last updated June 8, 2026