AI question paper generators work in one of three ways: retrieving items from an existing question bank, filling templates with varied values, or generating questions with a language model. The first two are reliable within their limits; the third produces questions that look correct and sometimes are not, which is the failure mode teachers should understand.
We do not generate questions and hold no question bank, so this is an explanation rather than a product pitch. Our own tool produces a blueprint and leaves the questions to the teacher.
Teachers evaluating a question paper generator are usually shown output rather than method, and the output looks fine. Understanding which of the three methods a tool actually uses tells you far more about whether you can trust it than reading a sample paper does.
Most products use a combination, which is worth asking about explicitly.
| Method | How it works | Where it fails |
|---|---|---|
| Retrieval from a bank | Items are written by people, tagged by chapter, difficulty and type, then selected to match a blueprint | Only as good as the bank. Repeats across a year; students recognise the set |
| Template with varied values | A question pattern with numbers substituted — a triangle with different side lengths each time | Works for computation, not for reasoning. Substituted values can produce impossible cases |
| Language model generation | A model writes new questions from a prompt describing the topic and format | Fluent and sometimes wrong in ways that look right. This is the one to understand |
A language model produces text that resembles a question about the topic. That is not the same as a question that is correct, answerable, and on the syllabus, and the gap between them is invisible at a glance.
None of these is common enough to make the output obviously useless, and all are common enough to make every question require checking. That is precisely what makes the saving illusory: verifying forty generated items carefully takes longer than writing twenty good ones.
Teachers do, and there are sensible ways to do it.
We hold no question bank and do not generate items. Our tool produces the blueprint — sections, question counts, choice, marks and the cognitive spread — and checks the arithmetic, which is the part that is genuinely mechanical and is where the errors found after printing actually come from.
The questions stay with the teacher, who can defend each one to a moderator. That is what makes it a paper rather than a worksheet.
Phrased the way they arrive, answered so each one stands on its own.
Ask where a specific question came from. A retrieval system can tell you which bank item it is and who wrote it. A generative one cannot, because the question did not exist until you asked.
Lower stakes, so lower risk, but a wrong question still teaches a student something wrong and they usually cannot tell. Solving them yourself first remains the minimum.
No. We produce the blueprint and check the marks arithmetic. We are the record, not the syllabus, and that boundary is deliberate rather than a gap we intend to close.
Checked by the Product desk on 7 September 2026. Corrections go in the page, dated, rather than quietly.
Pricing is on the page, in the open, with the counting rule written next to it. Nobody has to book a call to find out what it costs.
See pricingForty minutes with an implementation engineer — your classes, your fee heads, your grading scheme, entered as we go. No slides, no sample school.