Qwen3.6 35B built a release schedule locally on Ollama for Windows. A deterministic validator checked structure, availability, resources, durations, and dependencies. Every attempt and each check is shown as measured.
| attempt | total | load | rate | checks | what happened |
|---|---|---|---|---|---|
| Cold initial | 22.70 s | 14.15 s | 76.2 tok/s | 10/12 | Availability and dependency failures. |
| Warm identical | 8.40 s | 0.35 s | 75.3 tok/s | 10/12 | Same schedule and same failures. |
| Warm repair 1 | 9.24 s | 0.34 s | 76.2 tok/s | 11/12 | Dependencies fixed; one availability crossing remained. |
| Warm repair 2 | 9.26 s | 0.32 s | 75.9 tok/s | 11/12 | The availability error moved to different tasks. |
Every task was present. Durations were correct. The JSON parsed, resources did not overlap, and the fixed demo stayed in place.
Two checks flagged the first schedule: it placed people outside their availability and crossed two dependencies. The gap between a plausible-looking answer and one every check accepts is what this test measures.
The first repair cleared every dependency and moved the count from 10 of 12 to 11 of 12. One task still crossed Noah's unavailable noon-to-14:00 window by thirty minutes.
The next prompt named that single check and asked the model to recompute globally. The count stayed at 11 of 12, and the availability flag moved to tasks D and H. The answer changed; the same check kept catching it.
For a calendar, every hard constraint has to hold. A language model can read intent, propose a candidate, and explain tradeoffs; deterministic code or a constraint solver decides whether the schedule is usable.