What a JSON schema actually constrains
Under the hood, JSON mode works because the provider has the JSON grammar built in. The decoder is masked so the model can only emit tokens that keep the output a well-formed JSON value, and a schema layer narrows that further to your keys and types. So it's a grammar constraint, just one fixed to a single grammar, JSON, that ships with the model.
That's why it's reliable for JSON and silent for everything else. The moment your target language has constructs JSON can't express, like bare keywords, infix operators, indentation, or a custom statement separator, a JSON schema can't describe them. You're back to asking the model in a prompt and hoping the string parses.
When you need the full grammar
A full grammar-constrained decoder generalises the same idea to any language you can write down. You give dsl·ai your DSL's EBNF/GBNF-style grammar, it compiles that into the decoding mask, and at every step only tokens that keep the output inside your language survive. The guarantee matches JSON mode's, valid by construction, except the language is yours rather than the provider's.
A common middle path is to wrap your DSL inside a JSON string field and use JSON mode for the envelope. That guarantees the envelope, not the DSL inside it: the string can still be malformed in your language. A grammar constraint covers the part JSON mode leaves unguarded, and the same grammar then drives a deterministic validator so you can prove any string is valid.
JSON-schema constraint vs grammar-constrained decoding
| JSON mode / schema | Grammar-constrained (dsl·ai) | |
|---|---|---|
| Languages covered | JSON shapes only | Any language with a grammar |
| How it constrains | Built-in JSON grammar + schema | Your grammar compiled to a mask |
| Custom DSL / query syntax | Not expressible | Expressible and guaranteed |
| Validity guarantee | Valid JSON by construction | Valid in your language by construction |
| Verification | JSON schema validators | Deterministic parser from the same grammar |
frequently asked
Isn't JSON mode already a grammar constraint?
Yes, it constrains decoding to the JSON grammar specifically. Grammar-constrained decoding is the general case: you supply the grammar, so the same guarantee applies to your DSL or query language, not just JSON.
Can I just put my DSL in a JSON string field?
You can, and JSON mode will guarantee the envelope is valid JSON. It won't guarantee the DSL inside the string is valid. A grammar constraint covers the inner language, and dsl·ai can constrain and validate it directly.
Does my model need to support function calling for this?
No. Grammar-constrained decoding works on any open model served through a runtime that accepts a GBNF-style grammar, independent of whether it offers JSON mode or function calling.
How do I verify the output is valid?
dsl·ai generates a deterministic parser from the same grammar, returning valid, or invalid at a specific position with what it expected there. It's the equivalent of JSON schema validation, for your language.
Last updated June 8, 2026