A check you can actually block a merge on
To fail a build you need a verdict that's deterministic and explainable — the same input must always give the same result, and a developer must be able to see why. An LLM grader fails both tests: it can flip between runs and it can't point to the exact character that's wrong. A parser does both by definition.
dslai's validator returns valid or invalid, the furthest position it parsed to, and what it expected there. That's enough to print a useful CI annotation: 'invalid at position 21, expected "." or " for "' — the kind of message that gets fixed in seconds.
One grammar, generate and validate
The same grammar that constrains generation also drives validation, so the rules your team authors and the rules CI enforces can't drift apart. Update the grammar and both the generator and the gate move together.
That shared source of truth is the point: your DSL is defined once, and everything — playground, generation, CI — reads from it.
frequently asked
- How would this run in CI?
- Conceptually: point the validator at your changed DSL/config files and exit non-zero on the first invalid one, printing the position and expected token. A hosted CI check is on the roadmap; the engine that powers it is the same one in the free playground.
- Why not validate with the LLM that generated it?
- Because a model can be confidently wrong and isn't reproducible, so it can't safely block a merge. A parser gives the same verdict every time and names the exact failure.
- Does it work on config languages, not just DSLs?
- Yes — any language you can express as a grammar, including typed key=value config, route definitions, or alert rules. If a parser can describe it, dslai can validate it.
- What does an invalid result look like?
- Invalid plus the furthest position reached and what was expected there — for example, invalid at position 14, expected "%" or " for " but got "x".
Last updated June 7, 2026