Constrained generation: getting a specification, not text
If an AI must produce something, better make it produce an object a machine can fully verify. That's an active research field — and the first layer of Blueprint Maker's architecture. Article 2 of the “Research on determinism” series.
Constraining the shape: a problem research has solved
A free-running language model can produce any token sequence — including invalid JSON, a nonexistent property, an invented enumeration. Research has shown we can do better than fixing afterwards: constraining generation itself. The reference work reformulates generation as transitions in a finite-state machine: at each step, only tokens compatible with a regular expression or grammar remain allowed. The output is then well-formed by construction, at negligible overhead.
Later work refined the question — notably how to guarantee the grammar without distorting the model's distribution (too blunt a constraint can yield “well-formed but improbable” output). The established point: the STRUCTURAL validity of an LLM output is a mastered engineering problem, no longer a bet.
- Willard & Louf, Efficient Guided Generation for Large Language Models (2023): arxiv.org/abs/2307.09702
- Park et al., Grammar-Aligned Decoding (NeurIPS 2024): proceedings.neurips.cc
Why a specification verifies better than a program
The fundamental asymmetry is here: a specification is a DATA object, a program is a BEHAVIOR object. You can exhaustively check that a data object respects a schema — every field, every type, every relation, every enum value. Exhaustively checking the behavior of an arbitrary program, by contrast, doesn't happen by inspection: you must run it, test it, and accept partial coverage.
Having the model produce a specification rather than a program thus moves the AI's output to the verifiable side of that asymmetry. Whatever can be wrong in a well-formed spec belongs to the business domain (a misunderstood entity, a misinferred rule) — and that, a human can read and correct, which is exactly the role of the plan you validate before the build.
At Blueprint Maker: the AppSpec and its validation gates
Blueprint Maker's LLM produces a structured business schema — the AppSpec — in a closed vocabulary: entities, typed fields, relations, states, indicators. The spec then passes a chain of deterministic validators: foreign-key consistency, enum validity, naming constraints, database-schema validation by the official tool — with, on failure, regeneration passes under explicit constraint rather than silent correction.
The doctrine under persistent ambiguity is abstention: producing nothing beats producing wrong. A doubtful value is never “rescued” by invention — the same fail-safe principle that governs the product's whole integrity layer.
The honest limit: shape isn't meaning
Constrained generation guarantees a spec is well-formed; it doesn't guarantee it describes YOUR business. A schema can be structurally perfect and business-wrong. That's why the plan is shown before building: human validation bears exactly on what the machine cannot verify — meaning. The split is clean: conformity to the machine, relevance to you.