The 2026-obvious move, when someone hands you a contract and asks “how much late-payment interest is owed,” is to hand the whole thing to an LLM. Read the document, find the numbers, do the arithmetic, write the memo. One prompt, one answer. I built a legal-tech tool that does exactly this task — and I deliberately refused to let the model anywhere near the maths.
The split is the whole design. AI does extraction. A plain deterministic engine does calculation. No model ever multiplies two numbers.
Table of contents
Open Table of contents
What the AI is allowed to do
The LLM’s job is reading, and only reading. It pulls three things out of the contract: the amount owed, the date it fell due, and the interest rate the parties agreed to. Each one comes back with a page citation pointing straight back to the source document — this figure, from this page, this clause.
That’s it. Extraction with provenance. The model is doing the thing models are genuinely good at: understanding messy human prose, finding the relevant clause in a forty-page agreement, and telling you where it found it. It is not doing the thing models are bad at.
What the AI is never allowed to do
It never calculates. Once the amount, the due date, and the rate are extracted, they’re handed to a deterministic engine — ordinary code, zero AI — and the engine does the arithmetic. Same inputs, same output, every single run. No temperature, no sampling, no “usually correct.”
People push back on this. An LLM is right 98% of the time on arithmetic like this, they say, and getting better every quarter. Sure. But 98% is a catastrophe when the output has to survive a dispute. A model that’s right 98% of the time can’t give you reproducibility and it can’t give you traceability — and the 2% it gets wrong is exactly where a dispute lands. Nobody argues about the easy cases. They argue about the edge, and the edge is precisely where a probabilistic system is least trustworthy.
If a number can be challenged in front of someone with the authority to make you pay, “the AI computed it” is not an answer. “Here is the arithmetic, here is the rate that applied on each day, here is the clause it came from” is.
The engine does the boring, defensible part
The calculation is not one multiplication. A late payment can run for years, and statutory interest rates change over time. So the engine splits a long delay into sub-periods, cutting a new sub-period every time the applicable statutory rate changes. It handles simple versus compounding interest depending on what applies. And it emits a memo where every sub-period shows its own line: the rate that applied, the day count, and the source that rate came from.
Read the output and you can follow every figure back to its origin — the principal back to a page in the contract, each rate back to the statutory table it was drawn from, each sub-total back to a day count you can re-add by hand if you want to. Nothing is asserted. Everything is shown.
That is what “defensible” actually means in practice. Not “we used a good model.” It means any figure in the final number can be traced, re-derived, and argued from first principles.
Rates and conventions are data, not code
Here’s the part I’m most pleased with. The statutory rates, the day-count conventions, the compounding rules — none of that is baked into the engine’s logic. It’s all data. The engine is a pure function; the jurisdiction is a file it reads.
Which means a new jurisdiction is a new data file, not a rewrite. The maths of “split into sub-periods, apply the rate that held on each day, sum” doesn’t change when you cross a border — only the rate table and the conventions do. So you add a data file, and the same engine handles a second jurisdiction without a line of new logic.
And because the rates are versioned data, the engine is versioned too. A memo produced today can be reproduced next year, byte for byte, by pinning the engine version and the rate data it ran against. When someone reopens a calculation eighteen months later, you don’t shrug — you re-run it and get the identical number.
The takeaway I keep coming back to
The reflex in 2026 is to reach for the biggest model and let it do everything. Resist it where the output has to hold up. AI is extraordinary for judgment and extraction — reading a document, understanding intent, finding the clause that matters. It is the wrong tool for anything that must be reproducible, auditable, and defensible under challenge.
So split the work along that line. Let the model read and cite. Let deterministic code compute. The model tells you what the contract says; the engine tells you what that means in money, and shows its work.
Slides: the condensed version is in a short deck — download the PDF.
Where’s the line in your own systems between what an LLM decides and what it’s only allowed to hand to code that can prove its answer?