A specification that the LLM can choose to ignore is not a specification — it is a suggestion.
This distinction sounds philosophical. It is not. It is the difference between software that ships what was specified and software that ships what the model's next-token prediction felt like producing.
How Suggestions Happen
Every mainstream AI coding tool follows the same pattern:
- You write requirements in natural language.
- The LLM receives those requirements as part of its context window.
- The LLM generates output based on its training data, your context, and probability distributions.
- You review the output manually.
Step 3 is where enforcement disappears. The LLM processes your requirements the same way it processes any other text — as weighted context that influences generation. There is no mechanism that forces compliance. Your spec competes with the model's priors, its training biases, and the statistical likelihood of every token it emits.
When a spec says "maximum 200ms response time" and the generated code takes 400ms, no alarm fires. When a spec says "use PostgreSQL transactions" and the generated code uses raw queries, nothing breaks. The spec was context. The model considered it. The model decided otherwise.
From Suggestions to Gates
DuranteOS inverts this architecture. Specifications are not context for the LLM — they are acceptance criteria enforced by code.
The mechanism is called Ideal State Criteria (ISC). Every task decomposes into binary testable conditions:
ISC-C1: API endpoint returns JSON with required schema fields [PASS] ISC-C2: Response time stays below 200ms at 100 concurrent users [FAIL] ISC-C3: Database queries use parameterized statements [PASS] ISC-A1: No credentials appear in source code [PASS]
Each criterion is 8-12 words. Each resolves to pass or fail. There is no "partially met." There is no "close enough."
The LLM generates the work. Code verifies whether the work meets every criterion. If any critical criterion fails, the phase does not advance. The system retries or aborts. It never silently degrades.
Why Binary Matters
Partial compliance is where quality dies. "The API mostly returns the right schema" is how bugs ship to production. "The auth flow generally works" is how security vulnerabilities survive code review.
Binary gates eliminate the gray zone. A criterion passes or it fails. Passed means the evidence was mechanically verified — not self-reported by the LLM, not eyeballed by a tired developer, not assumed because the code "looks right."
This is the same principle that makes CI/CD reliable. Nobody ships code when tests fail. The gate holds because code enforces it, not because a human promises to check.
The Enforcement Stack
DuranteOS enforces specifications through three layers:
Criteria creation happens in the DEFINE phase. The system decomposes your request into ISC criteria. Each criterion is scoped to be testable — no abstract goals, no subjective assessments, no "improve performance."
Execution happens in the MAKE phase. The LLM writes code, creates files, spawns agents — whatever the task requires. The criteria are visible throughout. The LLM knows what it must satisfy but cannot decide whether it satisfied them.
Verification happens in the VERIFY phase. Code runs checks against every criterion. Evidence is collected. Pass or fail is determined programmatically. The LLM does not grade its own homework.
The Implication
If you accept that LLMs are probabilistic — that they can and will ignore, reinterpret, or drop specifications — then enforcement must live outside the LLM. It must be deterministic. It must be code.
That is the core architectural bet of DuranteOS: specifications are sacred, and the system that enforces them must be incapable of ignoring them.
The gate holds because it is not a suggestion.