Setting a question paper is a task with a deceptively rigid specification. The paper has to cover the right chapters, hit the right total, distribute marks across sections in the pattern the board expects, mix difficulty sensibly, and avoid repeating what the same class saw in the last unit test. Miss any one of those and the paper gets sent back.
Most school software helps with the last five per cent of this — formatting and printing — and leaves the hard part to a senior teacher and a Word document.
Why blueprint compliance is the hard part
A blueprint is a set of constraints applied at once. Section A wants twenty one-mark objective questions. Section B wants five three-mark short answers. Section C, in some patterns, mixes a five-mark and a ten-mark question inside a single section. Across all of that, the paper should be roughly a third easy, a third medium and a third hard, and the chapters covered should match what the class has actually been taught.
Filling that by hand means holding six constraints in your head while scrolling a question list. It is exactly the kind of work that is tedious for a person and mechanical for software — provided the software can read more than one blueprint format.
EdunodeX’s generator normalises a template section into individual question slots before it does anything else, and it handles three shapes. The first is the legacy template with a question count and marks per question. The second is the imported shape that uses a count and a marks-each value. The third is an explicit item list where each item carries its own mark value, which is what a mixed-mark section such as a CBSE SAFAL Grade 3 Section C actually requires. Sections produced from SAFAL templates are recognised by the pattern marker they carry rather than guessed at from their shape.
Every slot that comes out of that normalisation carries a section name, a question type, a mark value and a difficulty distribution. From there the generator is filling slots, not parsing formats.
Building a question bank worth drawing from
The generator is only as good as what it can draw on, so the question bank is a first-class module rather than a byproduct.
A question record carries its subject, its type, its text, its marks, its difficulty level, and optionally its options and correct answer, an explanation, a Bloom’s taxonomy level, an estimated time in minutes, and a link to the syllabus node it belongs to. That syllabus link is what makes chapter-wise selection possible: a paper covering chapters one to four is a query over syllabus nodes, not a keyword search.
The bank also carries a review workflow, which matters once more than one teacher contributes. A question written by a probationary teacher and a question written by the head of department should not carry the same weight in a board-pattern paper without someone having looked at it.
How the hybrid generator fills a blueprint
For each slot, the generator looks in the bank first. Subject, question type, mark value and target difficulty narrow the candidates, and the syllabus scope narrows them further. If a suitable question exists, it is used.
AI generation is the fallback, not the default. It fills the slots the bank could not — a five-mark question on a chapter nobody has written one for, an extra hard question when the bank only has easy ones on that topic. The call is routed through EdunodeX’s own AI proxy, which attributes the cost to the school and gives the platform a per-school cut-off, rather than to a provider SDK wired directly into the application.
This ordering has a compounding effect that is easy to miss. A school that reviews and keeps the AI-generated questions it liked has a better bank next term, so the next paper leans on the model less. The bank is the asset; the generator is the tool that makes the bank pay off.
Catching near-duplicate questions before printing
Two questions can be effectively identical while sharing almost no exact words. “Define photosynthesis” and “What is meant by photosynthesis?” will not match on a string comparison.
EdunodeX computes a similarity score from the question text itself — tokenised, lowercased, stripped of common stopwords, with very short tokens discarded — and compares questions by the angle between those vectors. It is a deliberately lightweight approach with no external machine-learning dependency, which means it runs inside the existing application rather than requiring another service to be up.
It is used in two places. In the bank, it surfaces likely duplicates so the same question does not get entered five times by five teachers. In generation, it diversifies selection so a single paper does not ask the same thing twice in different words.
Preview first, paper second
Generation and creation are separate API calls. The generate call returns a proposed paper. A second, explicit call confirms it and creates the stored paper record.
Between those two calls, a teacher can swap a question, rewrite one, change a mark value, or throw the whole draft away. Nothing has been written to the school’s records, so discarding costs nothing and there is no half-created paper to clean up.
Where a subject head still has to look
Three things deserve a human read before a paper goes to print.
Difficulty labels are the school’s own judgement. A question tagged “hard” by whoever entered it is hard by that person’s standard, and the generator honours the tag rather than second-guessing it. If a bank’s tagging drifts, papers drift with it.
Generated questions need a correctness check, particularly in mathematics and science where a plausible-sounding question can have no clean answer at the mark value requested. This is the strongest argument for reviewing AI-generated questions into the bank rather than using them straight off a generated paper: the review happens once, and every later paper benefits.
And coverage against what was actually taught is a teacher’s call. The system knows the syllabus tree and the teaching plan; it does not know that the class lost a week to a sports meet.