How We Use AI to Build a Quiz: The Whole Pipeline

"We use AI" is a sentence that hides more than it explains. On QuizByt a quiz passes through six stages before a child answers the first question, and a language model is responsible for exactly one of them. This article walks the whole thing, in order, so you can see where the machine helps and where it would do damage if it were left alone.

Stage 1: the topic, from a syllabus

Nothing is generated against "Class 5 Maths". It is generated against a named topic inside Class 5 Maths, and the list of topics is a catalogue in the code rather than something a model invents each time. The lists were assembled from published frameworks: Cambridge Primary Mathematics 0096, English 0058 and Science 0097 for the early classes, Cambridge Lower Secondary 0862 for Classes 7 and 8, a national secondary-board syllabus for Classes 9 and 10, and Cambridge O Level 4024 with IGCSE 0580 for O Level.

This sounds like a small detail and it is the foundation. A model asked for "five Class 5 maths questions" will cheerfully produce five questions scattered across five chapters, which is useless for a teacher who taught one of them yesterday. A model asked for "five questions on Prime and Composite Numbers for Class 5" produces something a teacher can set on Tuesday. How those lists were compared across boards is its own article: agentic AI and the syllabus problem.

Stage 2: the source material

Where the questions come from depends on which path triggered the build.

• A school's own PDF. A teacher uploads a chapter, and the questions are drawn from that chapter and nothing else. This is the path described in upload a PDF, get a lesson, a quiz and a worksheet.
• The existing question pool. For the monthly batch, questions already written and approved for that topic are drawn first, and the model is only asked for what is missing. A pool question has already been through review once.
• Neither. A topic with no pool and no upload is written from the syllabus description alone. This is the weakest input and it is the one most likely to produce something a reviewer rejects.

Stage 3: the draft

Now the model runs. It is given the class, the subject, the topic, the difficulty, the number of questions, and a schema it must return. The schema is not a suggestion: the response is parsed, and anything that does not fit the shape is dropped rather than guessed at.

The prompt also carries the rules a real classroom needs. Age-appropriate language for the class in question. One correct option out of four. A spread of sub-skills inside the topic rather than four questions on the same line of the chapter. For the younger classes, a requirement to mix question types rather than produce twenty multiple-choice questions in a row, because a seven-year-old answering twenty identical-looking questions stops reading them.

Stage 4: types and pictures

A question on QuizByt is not always four options and a radio button. It can be a set of tiles tapped into the right order, several blanks inside one sentence, items sorted into groups, or a set of pictures where the child taps the right one. The model is told which of these it may produce and in what shape, and the shapes are validated on the way in.

Pictures work through a small token language. Writing {pic:blocks:264} in a question draws base-ten blocks for 264; {pic:count:apple,7} draws seven apples; {pic:line:340,350,1,347} draws a number line with 347 marked. The same token renders as a drawn picture on screen and as a printable equivalent in a PDF worksheet, so one question carries its illustration into both without anyone drawing anything twice.

This is a constraint on the model and it is what keeps generated content consistent with hand-written content. A model that could emit arbitrary HTML would eventually emit something the player cannot render.

Stage 5: review

The quiz is written to the database with the status pending_review. Every query that lists quizzes for a student filters on approved. That means an unreviewed quiz is invisible because of how the data is queried, not because of a rule someone remembered to apply. Those are very different levels of safety.

From there it reaches a person in one of three ways: an administrator publishes it from the review desk, an administrator assigns it to a named teacher whose single approval publishes it, or, for a quiz written by a teacher, two different teachers approve it. The reasoning behind that structure is in the teacher portal: who checks the machine.

Stage 6: publication, and what happens afterwards

Approved quizzes appear for students in their class and subject, surface on the dashboard when they match a student's chosen topics, and become searchable. Each one carries its topic, so a result is recorded against that topic rather than against the subject as a whole.

After publication there is one more signal. Students rate how hard a piece of content was to follow, from 1 to 5. The average is ignored until ten students have voted, and anything averaging 2.0 or below goes back for review. A question that reads badly to thirty children is a fault in the question, whatever the adults thought of it.

Remove any stage and watch what breaks

Take out the syllabus catalogue and you get content that is technically correct and pedagogically random. Take out the type and picture rules and you get twenty identical multiple-choice questions that a Class 2 child will not finish. Take out the review and you publish wrong answer keys to real children, which is the one failure that is unforgivable. Take out the model and you are back to a teacher writing twenty questions by hand on a Wednesday evening.

All six stages, or none of it works. The model is the fastest part and the least trustworthy part, and the architecture around it exists because both of those are true at once.