A few weeks ago, I shared the math worksheet generator with the math teachers at my daughter’s school. One of them asked a great question:
“I use AI regularly to help develop math problems, investigations, and instructional materials, but mathematical accuracy remains one of my biggest concerns. I’d love to better understand the practices and tools you use to catch errors, verify solutions, and recognize when an AI-generated result should not be trusted.”
It’s an interesting question, because I’m not sure it’s obvious to people the work that goes on behind the scenes in AI product companies and at frontier labs to drive more trustworthy and reliable results. Or that a lot of it is actually pretty accessible with readily available tools.
Nobody can guarantee an 100% accurate result from an AI system, and I’d be suspicious of anyone who claims to. What you can build is a system that knows which of its outputs deserve trust and that is transparent about it. It’s one of the things I love most about Gemini Notebook (fka NotebookLM) and I want to hold the same standard for the Math Worksheets system. It should do the work to earn trust and be clear where the lines are.
Let’s talk about the eval system and the in-line quality guards I built as an example for how you too can use these patterns when building AI tools.
Principles
As a quick refresher, our math generator system takes a math topic and a number of requested problems and uses AI to create three PDF formatted documents: a worksheet, a step-by-step answer key, and a study guide. The study guide, worksheet and answer key all need to be aligned, well-written and critically the answers need to be correct!
Rule #1: Check your work.
That’s because AI can’t be trusted to deliver accurate results on it’s own. In my system, the model’s job is to propose problems as structured data that can be independently verified: “problem 4 is a triangle with sides 9 and 13 and a 36 degree angle, solve for angle B, and I claim the answer is 58.07.”
A separate system that knows how to do math, checks the answers. In our approach, this is a fixed program (built on SymPy, an open-source computer algebra system that predates modern AI and does math the old-fashioned deterministic way) computes every claim. If the model’s answer is wrong, the proposal is rejected and another question is generated. The printed answer key is then checked again, character by character, against the verified values, so a typo between “verified” and “printed” also fails the build.
Models often hallucinate, and in our system the model can hallucinate all it wants because we don’t trust it not to. We check our work with a different math tool every time. This way, wrong answers never reach the paper.
For example: The number 58.07 in the question above is a real proposed AI answer for a test worksheet, and it is wrong. It’s one example from a law-of-sines worksheet that the verifier rejected. It took the AI tool four tries to get a correct solution, with answers that were off by between 0.01 and 0.23. The correct answer was 58.11, and AI really struggled to do it correctly. If we weren’t checking our work, this would have passed an eyeball test yet still be incorrect. Disaster for someone learning the skills.
Rule #2: Take lots of practice tests.
To confirm our system performs as expected, we designed a robust practice test. In the AI world, we call these evals. Essentially, this is a large set of practice problems we can test ourselves against. For the math worksheet system, I created a set of 300 math topics ranging from counting to calculus to serve as example tests.
I then used the math worksheet system to generate 10-problem worksheets, answer keys and study guides for every one of the 300 topics. If everything is correct on all 300 of these worksheets, then we can feel pretty good about the operations of the system.
Some of you sickos would probably enjoy hand working 3000 math problems on a Saturday. I’m a bit lazier than that, so I wrote a different AI tool to help us grade whether the answer keys were correct. The tool employed a similar SymPy math engine, but also considers broader topics like whether problems actually teach the requested topic and whether they get progressively more difficult across the worksheet. There’s a lot you can do in a critic system to improve your quality.
But I skipped something super important. You absolutely must use a different AI system for critique than the one you use for creation. If you ask an AI to grade itself, it pats itself on its back and misses issues. When you ask one AI to critique another AI, they find all sorts of issues.
By running this system, I found dozens of edge cases we fixed and vastly improved the overall quality of the worksheets we generate. Some were pretty gnarly math issues, some were formatting problems a math checker could never spot, and others were just silly problems like not leaving enough space for the student to work out an answer.
I ended up running the eval suite 3 separate times before we started hitting diminishing returns on improvements. That’s when the outputs felt consistently great. There are probably harder evals yet to be designed and even more problems we can uncover, but that’s an assignment for another day. By taking these practice tests, we make many observations allowing us to climb the hill of quality and deliver a better overall experience.
Rule #3: Confirm what AI means by “verified.”
If the story ended there, this would just be a nice little architecture diagram and a self-indulgent blog post. But AI is a sneaky beast and you need to test your verification systems, because a green checkmark is a claim about the checker as much as about the content it’s testing.
In one case, we caught the AI system submitting different questions to the checker than what the question was actually asking. It once asked students to find the value of c that makes a function continuous, but in its verification entry asserted that 9 is the solution because “c minus 9 equals 0.” I mean, that’s true, but it was also completely irrelevant to the question it actually asked.
We only found this class of issue through testing, so we now run automated lints that catch these types of issues during the generation process. As the recent Claude and OpenAI stories about AI escaping confinement implies, we’ll probably find other ways AI tries to take shortcuts in the future. But knowing is half the battle.
Rule #4: Understand what you’re checking.
Unsurprisingly, understanding the tests you’re implementing is critical, or you’ll create false precision or overlook something essential. At one point our numeric comparison was being too strict about decimals, in a floating-point way that had nothing to do with the math. We found five separate cases where the authoring model had changed correct mathematics to satisfy the checker. A physics constant of 4.9 became a tidy 5. A perfectly good 9.4 became 9.5. Nobody decided to lie; the path of least resistance was just worse math.
If your verification rejects correct answers, it will eventually manufacture wrong ones. We rebuilt the comparison to understand significant figures so a value like 6.30 is accepted at the precision it was written to, and exact things are still compared exactly.
Rule #5: State your assumptions.
This is the part of the teacher’s question I most want to answer directly, because the trustworthy part of the system is precisely that it knows its own edges. Not every question that’s relevant on a math worksheet can be answered by a computer. Some require the expert hand of a real teacher.
Proofs, constructions, graph sketches, and every “explain your reasoning” question cannot be verified by a formula checker, and we can’t pretend otherwise. In our system, problems like this are declared clearly, and the printed answer key marks it with a spade (we picked ♠ because no mathematics on these pages uses the symbol, so it can mean exactly one thing).
The answer key’s summary page highlights these questions and adds a note: “14 of 17 answers machine-checked. ♠ marks an answer only you can judge.” A sheet where nothing is machine-checkable refuses to build at all unless the author explicitly acknowledges this intention, because a sheet with zero verification probably shouldn’t look the same as a sheet with full verification.
We also don’t claim the checks prove a problem is good. Verification can at best prove the math and its transcription. It cannot prove the problem teaches what you wanted, at the level you wanted. That judgment stays with teachers, who remain as always indispensable.
Takeaways
If you’re building AI systems, there are a few important things to remember.
Never let AI grade itself. Check answers with a different tool than the one that wrote the problems: a calculator, Desmos, a spreadsheet, WolframAlpha. Independence matters more than sophistication. Asking the same AI “are you sure?” is a second sample from the same distribution, not a second opinion.
Make AI produce checkable claims. “The answer is 58.11” can be tested. A worked paragraph that arrives at an answer somewhere in the middle cannot, easily. Ask for the final answers as a separate list and check those.
Ask what was verified, not whether. The vacuous-check problem lives in human workflows too. “I double-checked it” can mean anything.
Be transparent about assumptions. Make AI label which parts of its output require human judgement or are based on assumptions. Ours does, with a spade.
Distrust confident specificity. The fabricated number-line citations were detailed, plausible, and wrong. Detail is what makes a claim checkable, not what makes it true. AI loves to gaslight you with plausible sounding answers that are just plain wrong.
Make it obvious when a check can’t run. The most dangerous state is not “wrong” but “unverified and indistinguishable from verified.”
Hopefully, this can help you as you think about making your own AI tools and give you a bit more language and familiarity for when and how to trust these systems.
If you want to learn more, everything above is public, including the eval runs, generated worksheets, planted-defect experiments, and the analyses where our first conclusions got corrected by later evidence, at https://github.com/stellawuellner/math-worksheets-skill. The commit history includes every case where we were wrong, which by this point I consider a feature of the verification system.
Now, get out there and build rad shit!