How to use an AI worksheet generator without shipping a wrong answer key

A worksheet generator makes a student-facing artifact

The deliverable is the sheet in a student's hands

A worksheet is not a document about teaching. It is the thing that comes out of the photocopier twenty-eight times, gets written on in pencil, and is marked against a key. That makes it unusually easy to judge. Either the items practise the skill, or they do not. Either the page has room to work in, or it does not. Either the key is right, or you spend the lesson apologising for question 17.

If the output you got has objectives, a timing column, and a differentiation table, you asked for a different artifact. That is the teacher's planning document, and it belongs in the AI lesson plan generator workflow. A worksheet generator's job starts after the plan exists and one line of it says “independent practice, twenty minutes.”

Four things the sheet has to get right

1. The item set. Items that practise one skill, are not the same item four times with different numbers, and do not quietly require a second skill the class has not met.
2. The progression. A ladder a student can climb alone, because nobody is standing next to them.
3. The layout. Working space, legible at 100% in black and white, no colour-only cues, nothing clipped at the margin.
4. The key. Correct. This is the one that fails, and it fails without looking like it failed.

Specify the items, not the topic

Use this six-step workflow

1. Name the skill and paste the objective text from your source.
2. Fix the item count and the difficulty ladder.
3. State number ranges, item forms, and distractor rules.
4. Make the model compute the answers, never recall them.
5. Check the key and print one copy before the class set.
6. Keep the generator so the next version costs a minute.

Number ranges are the difficulty control

“Make a fractions worksheet for Year 6” is a request for anything. The generator will pick its own difficulty, and it will pick the middle, so the sheet will be too easy for a third of the class and impossible for another third. Difficulty in practice items lives almost entirely in the numbers: the size of the operands, whether a sign flips, whether a division comes out whole, whether a denominator is one the student has automatised.

Write those as constraints. “Denominators drawn from 2, 3, 4, 6, and 8. No answer greater than one. No two items sharing the same pair of denominators.” A constraint like that is also a machine check later, which is the second reason to write it down.

Distractors are error modes, not decoys

If the sheet is multiple choice, say what each wrong option is for. “One distractor from a sign error, one from dividing before subtracting, one from the correct answer with the operations reversed.” Distractors invented for plausibility teach nothing and occasionally teach the wrong thing. Add one mechanical rule: no distractor may equal the correct answer, and no two options in an item may be equal. Both are one line of code and both catch real generated sheets.

Assume the answer key is wrong until something has checked it

This is the failure mode, not a footnote

A model asked for thirty answers will produce thirty confident ones. Some will be wrong, and the wrong ones look exactly like the right ones — there is no hedging, no lower confidence, no visible seam. Arithmetic is the worst case, because generating variants of one template by changing the numbers is precisely the operation that degrades accuracy.

“performance of all models declines when only the numerical values in the question are altered”

Mirzadeh et al., GSM-Symbolic

The same paper reports that adding a single clause which looks relevant but contributes nothing to the solution dropped accuracy by up to 65% across the models tested. A word problem is a pile of such clauses. So the honest position is not “check a few answers.” It is: an unverified key is not a key.

Make the model compute, not remember

Two mechanics remove most of the risk, and they are cheap.

Build the item backwards from the answer. Pick the solution first, then construct the question around it. For ax + b = c, choose x and a and b, then compute c. The key is now correct by construction, and difficulty constraints become filters on the parameters rather than hopes about the output.

Verify forwards, independently. Take the printed question and the printed answer, substitute one into the other, and assert they match. Do it on the exact strings that will be printed, not on the variables in memory, because that also catches formatting bugs. Use exact arithmetic — Python's fractions.Fraction rather than floats — so 1/3 does not print as 0.33 and then fail its own check.

NIST's generative AI profile names confabulation — confidently presented false content — as a specific risk of these systems. A worksheet key is a dense, low-redundancy list of facts with no prose around them to make an error look odd. It is close to the worst possible place to trust recall.

Worked example: 24 two-step equations with a verified key

What OpenCraft actually runs

OpenCraft's runCode tool starts a durable job in a real Python sandbox attached to the conversation, so the model does not describe a calculation, it executes one. Files the job writes into its outputs/ folder come back as downloadable artifacts. The sandbox workspace persists between turns, which matters more than it sounds: the generator script is still there next turn, so “same rules, new numbers, and make block 4 harder” is a re-run with a different seed rather than a fresh guess.

For the document itself, makeDoc turns reviewed Markdown into an editable .docx plus a doc-styled HTML preview you can print from the browser. If the sheet needs a diagram — a number line, a labelled shape — an SVG artifact is checked by a deterministic linter that flags overlapping and out-of-canvas text, so the model gets told its labels collide instead of shipping a figure nobody can read. Re-running the same filename stacks versions rather than overwriting, so worksheet A and worksheet B stay side by side.

The run, end to end

1. You give the spec above: skill, 24 items, four blocks, ranges, and the layout rules.
2. The job writes a generator: choose x, a, b within the block's constraints, compute c, reject any item whose parameters repeat an earlier item's, keep going until the block is full.
3. The same program re-solves each printed equation from its printed text and compares with the printed key. It prints one check line per item, so a failure is visible in the job output rather than on the page.
4. The items and key go into Markdown, and makeDoc returns an editable document plus its preview.
5. You solve three items chosen at random by hand, print one copy at 100%, then run the class set.

The interesting part is step 3. Rejection and regeneration are normal — a duplicate pair of parameters, a solution that lands outside the stated range — and a run that reports zero rejections across four blocks of tight constraints is worth a second look, because it usually means the checks were not actually wired to the printed strings. You can also compare AI models if you want a cheaper one for the routine sheets and a stronger one for word problems.

The checks that catch a bad worksheet

Six minutes, before the photocopier

The print test is the one people skip and the one that costs a lesson. Screen layout lies about margins, and a sheet that assumes colour becomes a grey puzzle in the copier. Print it, put a pencil on it, and see whether there is anywhere to write.

What a worksheet cannot do

Practice is not assessment

Retrieval practice is genuinely well evidenced. The 2013 review by Dunlosky and colleagues for the Association for Psychological Science rated practice testing and distributed practice as the highest-utility techniques among the ten it examined, ahead of familiar habits such as rereading and highlighting. That is a good reason to hand out worksheets. It is not a reason to believe a finished sheet tells you what a student understands.

A score on unsupervised practice conflates knowing, guessing, copying, and running out of time. What you learn from a worksheet is mostly in the working, not the answer — which is an argument for leaving room to write and for reading a few sheets properly rather than totting up ticks.

Generated practice can drill the wrong thing convincingly

This is the specific danger of a fast generator. Thirty fluent, well-formatted, correctly keyed items can still be practice for a procedure the class already has, or for a slightly different skill than the one you named, or for a strategy you were about to move them off. Nothing on the page reveals this. The sheet looks like a good sheet. Volume is the easiest thing to generate and the least informative thing about quality.

It cannot see your class, or certify a standard

The generator does not know who reads slowly, who has an access arrangement, which context will land badly, or what went wrong last week. Those belong in the brief, in your words. And do not let a model supply a standard code from memory: paste the exact code and wording from the official source your school uses, whether that is the Common Core mathematics standards or a national curriculum document. A sheet labelled with a benchmark it does not actually address is worse than an unlabelled sheet, because it stops anyone from checking.

For the planning document that sits above the worksheet, see the AI lesson plan generator guide, or browse the OpenCraft use-case library for other deliverables.