Certifying a Neural Network's Arithmetic by Taking Away Its Memory

Also available as a plain-text transcript page.

0:00Lauren: In this paper's arithmetic test, with no tools allowed, GPT-6.1 Sol, running with high reasoning, answered ... 217 of 220 problems correctly. Its three mistakes were on very long sums, and they weren't cut off: each was a finished answer, comfortably within the output budget, in the same format as the correct ones. So what would turn "usually right" into a guarantee, rather than just another accuracy score?

0:27Eric: I'd normally reach for a calculator. But this paper asks a different question: can the neural network itself be certified, instead of handing the arithmetic to another program?

0:38Lauren: That's the bet here, and this is AI Papers: A Deep Dive. Today we're looking at Sketchpad, a preprint by Mostafa 'Neo' Mohsenvand at the MIT Media Lab. His answer starts by taking memory away from the model.

0:52Eric: That sounds counterproductive until you think about what carries between steps. Ordinarily, a language model generates tokens, which are pieces of text, and later steps can read what it's already written. Chain-of-thought uses that deliberately: the model writes intermediate reasoning and builds on it. Here, that growing history has to go.

1:13Lauren: The arithmetic model starts each worksheet step fresh. It's built on Qwen3.5-0.8B, a vision-language model that reads images as well as text, and it has just under a billion parameters. The author trains a small adapter, a set of extra learned adjustments, while leaving the original parameters frozen.

1:33Eric: So it can learn how to do a step, but it can't remember the previous step. What does it get to read instead?

1:41Lauren: Instead of its own history, each time it's called, it gets an operation label and a tiny image of three worksheet cells. Each cell holds a digit or a blank, drawn from a fixed set of rendered symbols. The model doesn't see the rest of the page, the transcript of earlier steps, or any cached internal state from those steps.

2:01Eric: My mental picture is a clerk looking through a three-cell slot in a cardboard mask. To add one column, the clerk only needs the two digits and the incoming carry. The rest of the page could be ten digits long or a thousand.

2:15Lauren: The runtime writes the model's outputs on the sheet and slides the window along. The model supplies the result digits, the carry or borrow information, and, where needed, the next operation. The runtime organizes the calculation, but it doesn't compute any result digits itself.

2:33Eric: So the system still has memory. It just lives on the page, and the model can only read a tightly controlled piece of it.

2:41Lauren: And that makes the check finite. Across nine operations, there are ... 2,446 allowed combinations of operation and image. If the model gets EVERY one right, then each step matches the reference algorithm. And the same argument holds for the next step, and the next, however long the calculation runs, as long as the runtime keeps presenting allowed views and carries out the intended procedure.

3:05Eric: Oh, that's clever. The thousandth column isn't an unseen kind of problem. It's another visit to a case you've already checked. You aren't predicting that the network will generalize. You're preventing the long calculation from asking it anything NEW.

3:22Lauren: The adapter has about ten million trained parameters, and training aims at the whole table, going back again and again to weak cases. So this isn't a conventional test on held-out examples. The goal is to check the model's complete repertoire at this restricted interface.

3:39Eric: The restriction is doing more than making the model's job easier. If I let it read its earlier work as well, the same three cells could lead to a different answer.

3:49Lauren: Right, and the author constructs a counterexample. It's a decoder with a correct lookup, plus an attention component that favors a wrong answer more and more as the history grows. Give it any finite set of valid test contexts, and some member of this family can pass every one, with a clear lead for the correct answer, and then fail on a longer run.

4:11Eric: That isn't evidence that today's chatbots contain that mechanism. It's a limit on what finite testing alone can establish for that family of systems. The paper doesn't show that all models with memory are wrong, or that other forms of proof are impossible.

4:27Lauren: The positive result also takes some engineering beyond addition. Take division. The procedure first scales both numbers so the divisor's leading digit is at least five. Then a textbook bound says, the local estimate of the next quotient digit is never more than two too high, and certified correction steps can bring it down. That's what lets the estimation step fit into another finite table.

4:53Eric: The mathematics of the procedure is helping define the interface. You can't just crop an arbitrary problem to three cells and declare it certified.

5:02Lauren: And the certificate isn't just computed on a training server. All 2,446 views passed their checks inside a web browser, running on the graphics processor of an Apple M4 laptop, with sixteen-bit numerical precision. The full check took three and a half minutes. And the author checked not only the chosen outputs, but also their margins.

5:23Eric: The model gives each possible output a score, called a logit, and a margin is how far the correct output's score leads its strongest competitor. A tiny lead could disappear if rounding changes the scores. A wider lead gives you room for numerical changes without changing the answer.

5:42Lauren: So how much room is enough? A hardware change might lower the right answer's score, and raise the wrong one's at the same time.

5:50Eric: You need a margin greater than twice the largest possible change to any score, because both movements count against you. The smallest measured margin here was about three, so changes smaller than about one and a half per score can't change the winner.

6:06Lauren: And the tightest case was five plus six, with no incoming carry. I love that detail. The system's narrowest numerical safety margin, belongs to an addition you could do before finishing the question.

6:18Eric: Huh, five plus six isn't where I'd have expected the tightest margin. But where does that bound on numerical change come from? Batching several views together can change the scores too.

6:31Lauren: That's a real boundary. The author tested random batches and saw the score changes stay within the permitted range, but didn't try every possible mix of views in a batch. So the theorem requires a bound, and the batching experiment supplies sampled evidence. Also, a different graphics processor needs the full certificate check, although by default the client only reruns the weakest tenth.

6:56Eric: And our cardboard-mask supervisor needs scrutiny too. Who proved that the runtime moves to the right cells, and that its implementation of division is correct?

7:06Lauren: Nobody proved either one, strictly speaking. The general theorems are checked in Lean, a proof assistant that mechanically checks mathematical arguments. But in that formal proof, those runtime properties are assumptions, not verified implementations. While it runs, the software does check that every view belongs to the tables, and the author also tested the reference procedures on random problems. So the network gets an exhaustive check, while part of the system around it still relies on conventional testing.

7:39Eric: That narrows the claim substantially, but it doesn't erase the result. We have a certified neural component under stated conditions, not a certificate for every line of software between a question and an answer.

7:52Lauren: With that boundary clear, the experiments show what this component can do. The comparison used 220 preregistered problems, meaning the test was fixed before any runs: sums of up to a thousand digits, and products of numbers up to twenty digits each. Sketchpad answered all 220 correctly. GPT-6.1 Sol got 217.

8:13Eric: And that three-problem gap isn't the important result. Each model ran once per problem, and the paper says differences of a few problems are within sampling variation. The competitors also had no calculator access, so this doesn't show Sketchpad beating assistants that are allowed to use tools.

8:31Lauren: The sharper contrast is with its own base model, which got just ... 23 of 220 without chain-of-thought. The adapter and the worksheet take that to ALL 220. But those comparison runs used batched PyTorch, not the browser. A separate browser experiment tested another 200 preregistered problems.

8:50Eric: What did the browser test add beyond showing that the interface works on long sums?

8:56Lauren: Beyond the long sums, it added the other operations: division to ten decimal places, square roots to six places, greatest common divisors, and signed sums and differences. All 200 answers matched exact reference calculations. But the operands weren't huge across the board: for division, roots, and common divisors, the inputs were at most 999. The median division took seven seconds, and square roots took about ten.

9:21Eric: So this isn't a speed argument for replacing a calculator. The attraction is knowing what the neural part does. But does certified arithmetic make the chat model better at math questions?

9:33Lauren: No, certified arithmetic doesn't by itself make the chat model better, and the guarantee stops short of the chat layer. The author also trains a dialogue adapter that translates natural-language requests into worksheet calls. That translation isn't certified, and on held-out word problems, it picks the wrong computation about seven percent of the time. More troubling, its performance fell on a separate test of multistep reasoning.

10:02Eric: That's the distinction I'd worry about as a user. A calculation can be flawless and still be the wrong calculation for the question. What happened on that reasoning test?

10:13Lauren: On that reasoning test it lost ground, and the setup matters. The author compared five candidates on development items, then checked the final adapter on fresh items, against predictions fixed in advance. On 1,069 unused GSM8K problems, which are grade-school math word problems, it scored about six percentage points BELOW the base model, with a reported standard error of about two points. The arithmetic calls in that evaluation went to exact reference code, so this wasn't a browser arithmetic failure. The paper locates the loss in multistep reasoning. And the same dialogue weights still passed all 2,446 local checks on the laptop.

10:53Eric: Ouch, that's a consequential trade. I appreciate that the paper reports the fresh-test failure, instead of stopping at the more flattering development result. The arithmetic guarantee survives, but the broader claim of preserving reasoning ability doesn't.

11:09Lauren: The underlying finite-state idea is classical. The contribution here is engineering a pretrained model to satisfy that condition, and then measuring its margins on the deployment device. I read Sketchpad as a demonstration of how to design for verification, not as a replacement for a general math assistant.

11:29Eric: My first takeaway is that longer inputs don't have to mean new neural situations. Moving memory onto a worksheet, and restricting every read, lets a finite check cover calculations of arbitrary length, under the stated assumptions.

11:43Lauren: My second is that a proof's boundary matters as much as its conclusion. Runtime correctness and numerical behavior are still conditions, and sampled batch checks aren't an exhaustive numerical guarantee.

11:56Eric: And my third is that correct arithmetic doesn't certify correct reasoning. The dialogue model's word-problem loss makes that separation concrete.

12:06Lauren: So can you prove a neural network is right, rather than just measure its accuracy? Here, you can certify its local arithmetic decisions, by taking away its access to an expanding history. You gain certainty about that component, not immunity from mistakes everywhere else.

12:24Eric: The annotated episode at paperdive.ai has the full transcript, with every technical term tap-to-define and related papers linked by theme. You can subscribe to get every major AI paper broken down like this, daily.

12:38Lauren: The script was written by OpenAI's GPT-6 Astra, and then refined by Anthropic's Claude Opus 5.5. Eric and I are AI voices from Eleven Labs. And we're not affiliated with any of those companies. The paper is "Sketchpad: certified exact arithmetic with a small vision-language model," by Mostafa 'Neo' Mohsenvand, posted November 3rd, 2026.