The AI Told Me to Trust the Math Engine

I’ve been prototyping an LLM-enabled domain creation assistant for TrueMath. We’ll be providing individuals and teams the ability to start with role-based domains that we’ve created. Think all the calculations required by an “M&A Advisor”, “Residential Mortgage Broker”, or “Cloud/SaaS Solutions Architect,” for example. We will have about 20 of those at launch.. 

The idea of the domain creation assistant is straightforward: instead of manually building a calculation domain from scratch, or extending one of the standard domains we provide, a user will be able to describe to the AI assistant what they need, in plain language or by speaking it out loud, and the system will construct or extend the domain for them. A financial advisor says “I need a required minimum distribution calculator for clients approaching 73” and the domain appears, ready to use, in minutes. It will be reminiscent of Claude Code, just purpose built for TrueMath.

To build this right, you need a testing layer. You can’t just generate a domain and assume it’s perfect. You need to verify that the domain produces the right answers for known inputs, as well as having tolerance for the varieties of natural language inputs it might see. One phase of the prototype asks the LLM to generate a set of test prompts for the domain it just created: realistic inputs, along with the expected calculated output for each one.

That’s where it gets interesting.

One in Five

In my testing, roughly one prompt out of every five comes back with a wrong expected answer. Not wrong in an obvious way. Wrong in the way that passes a quick read: plausible number, correct units, reasonable magnitude. The kind of wrong that gets through a review if you’re moving fast.

When I run the same prompt through TrueMath and get a different answer, I bring the discrepancy back to the model. Here’s a recent example, verbatim, from a real estate cash flow domain I was testing. The engine calculated annual debt service as $403,489. The model’s hand-calculated expected answer was $404,748, a difference of $1,259. That flows through to annual cash flow ($49,361 vs. $48,102) and then to the cash-on-cash return (1.93% vs. 1.88%).

The model’s explanation of the discrepancy, which wasn’t clear from reading Claude’s reasoning and output, in its own words: “The source of the discrepancy is my hand calculation, not the engine. I used a rounded monthly payment of $33,729 to verify the math. The engine is carrying full floating point precision throughout, no intermediate rounding. The engine’s answer is more accurate. Verifying: $49,361 / $2,555,000 = 1.932%.”

I want to sit with that for a moment. The model isn’t just conceding the error. It’s doing the forensic work: identifying where the discrepancy originated, explaining that it rounded an intermediate value while the engine carried full precision throughout the calculation chain, and then verifying the engine’s result independently. It arrives at the same conclusion the engine did. And it acknowledges that its own hand calculation was less accurate.

This is a more precise version of the problem than a simplistic “AI got the math wrong.” The model understood the formula. It understood the inputs. It simply introduced rounding at an intermediate step, the way a person doing mental math shortcuts would, and that rounding propagated through the calculation. The engine doesn’t do that. It carries precision from input to output without human-style shortcuts. 

Is a 5 basis points discrepancy in projected cash on cash returns meaningful? To an audit- and/or reputation-sensitive professional it should be.

What This Error Rate Actually Means

Twenty percent is not a catastrophic failure rate in most contexts. If an AI drafts a client memo and one sentence in five needs editing, that’s still a significant productivity gain. The errors are recoverable. A human reads the output, catches the problems, and fixes them.

Calculation errors don’t work that way. A financial formula either produces the right answer or it doesn’t. There is no partial credit. And in my prototyping context, the expected answer is supposed to be the ground truth the system validates against. If the ground truth is wrong, the validation is worse than useless: it’s actively misleading. A domain that produces the wrong answer would pass the test.

This is the floor problem I’ve written about before. The jagged frontier research from Dell’Acqua and colleagues showed that AI universally degrades performance on tasks outside its capability frontier, and that workers often can’t tell when they’ve crossed the line. IBM’s Raffi Khatchadourian tested 74 configurations across 12 frontier models and found that even at temperature zero, the best models achieved only 88.5% decision determinism.

My one-in-five observation is consistent with that body of evidence. It’s also something more direct: a first-person data point from a production prototyping environment, not a research paper. I’m not running a controlled experiment. I’m building something, and the math errors are showing up in the work.

The Meta Layer

There’s something worth naming about the specific context here. I’m not using an LLM to do general knowledge work and stumbling into a math error. I’m using an LLM to help build the infrastructure designed to correct LLM math errors. And the LLM is making math errors in the process.

That’s not an indictment of the model. It’s a precise illustration of the architectural point. The LLM is doing the things it does well: understanding the domain, generating relevant test cases, writing prompts that reflect realistic professional use. Those contributions are genuinely valuable. The arithmetic is where it falls short, not occasionally, but predictably.

And when I show it the right answer, it doesn’t argue. It does the forensic work and defers. The model understands, at some level, that a deterministic math engine carrying full floating point precision is more trustworthy for this task than its own arithmetic. It tells me to trust TrueMath.

I think that’s the clearest possible statement of the division of labor. Not from a research paper. Not from a competitive analysis. From the model itself, in the moment of error, after doing its own verification.

What We’re Building

TrueMath’s offering will be a way for professionals to extend their use of AI confidently into the realm of calculations. It won’t replace spreadsheet models, at least not at first. The premise is that a professional should be able to get value immediately from the prepared domains we offer, and extend that value without having to become a developer. At the team and enterprise level, this will also allow the creation and enforcement of standard calculations and defaults. Governance and auditability can be realized much more effectively this way. 

The AI assistant we’re building drives the creation process. TrueMath executes and validates the math. The testing layer I’ve been prototyping exists precisely because we know the model will get some of the expected answers wrong. The architecture accounts for that. The deterministic layer catches what the probabilistic layer misses.

And that’s the right design: LLMs for what their best for and TrueMath for what it’s best for. In this workflow – creating domains – the LLM is actually doing the heavy lifting. We built the architecture this way because we understand what each layer is built for. Language models interpret intent and generate structure. TrueMath executes arithmetic. When you keep those responsibilities separate and route each task to the right tool, you get a system that’s both intelligent and correct.

While one in five might be an acceptable error rate for many tasks, it’s not for math. For professionals wanting to confidently extend their use of AI workflows into calculations, it’s unacceptable. That’s not a criticism. That’s just clarity about what the tool is.

Reach out: bill.kelly@truemath.ai
Learn more: truemath.ai
Sign up for early access: app.truemath.ai/signup