> From https://dialect-engineering.ai/sections/10-schema-and-grammar, the companion site to the paper "SaaS architecture when code is cheap". Draft, September 2026.

# SaaS architecture when code is cheap

## 10. Configuration schema and grammar

Most mature products already have something in this territory: a schema per feature stating which attributes that feature takes. Where AI has been introduced into a setup process, the usual shape is a model reading the customer's documents and mapping what it finds onto that schema, with a person reviewing the result.

This is the right first step, and it hits three limits in sequence.

**The schema has to carry every permutation.** In most products the configuration sits in setup screens, spreadsheets and files in formats such as JSON, YAML or XML. A schema for those files lists the fields and their types, and can express only limited conditional rules, such as that an attribute is only valid in certain combinations, or that one value constrains another, so every legal variation has to be enumerated as structure. The schema grows with the product's flexibility, and the growth is combinatorial.

**Instructions in prose are not enforceable.** The rules a schema cannot hold get written as markdown instructions or agent configuration. Prose instructions are read as guidance, and nothing checks the output against them. Two separate gaps open. The output may not match what the instruction said, and it may not match what the software needs, because a field being the right type says nothing about that field's relationship to the rest of the configuration.

**Review stays per attribute.** Because neither gap is machine-checkable, the human approval loop runs over every line and every attribute on the screen. This is the cost that does not amortise. It scales with the volume of configuration rather than with the number of features.

A grammar addresses all three at the same point. It uses the same underlying structure as the schema, which makes it an increment rather than a restart, and it adds the rules as formal constructions that a parser enforces. A markdown instruction is guidance that a model interprets, whereas the parser applies a grammar rule the same way every time.

| | Schema plus prose instructions | Grammar |
|---|---|---|
| Structure | Enforced | Enforced |
| Conditional and cross-field rules | Prose, advisory | Formal, enforced by the parser |
| Invalid request | Mapped to the nearest valid structure | Refused, with a location and a reason |
| Semantic check | Human review, per attribute | Functional tests, run by the agent |
| Error surfaces | Structure at authoring time, cross-field rules after the configuration is applied | Structure and rules at authoring time, behaviour at test time |
| Editor and agent support | Standard for structure, none for cross-field rules | Standard for both, through the Language Server Protocol |

Evidence that the grammar does work, beyond documenting, comes from grammar prompting: putting a grammar in the model's context lifted in-distribution accuracy modestly and lifted out-of-distribution accuracy on previously unseen functions from 63.3% to 90.8% ([Grammar Prompting for DSL Generation](https://proceedings.neurips.cc/paper_files/paper/2023/file/cd40d0d65bfebb894ccc9ea822b47fa8-Paper-Conference.pdf), NeurIPS 2023). The gain concentrates on constructions the model has never seen, which is where a bespoke product language sits.

---

---

Previous: [9. A grammar above the graph](https://dialect-engineering.ai/sections/9-grammar.md) · Next: [11. Degrees of freedom and what they cost](https://dialect-engineering.ai/sections/11-degrees-of-freedom.md)