A receipt for every model

What we built, and what it does

Our present work is a way to make that receipt. For the training runs covered by our research, an ordinary computer with no GPU can predict what the hardware will produce, then compare the result down to the byte. The answer can be written before the hardware is rented. The comparison has something fixed to stand against.

Two papers describe the work and its boundaries. Paper 1 and Paper 2, linked at the end of this note, lead to their publication previews. What follows is the idea, what we have found, and how far the evidence reaches.

What a receipt is

A receipt is a set of instructions for redoing the work, and a set of checksums for knowing whether the answer agrees. That is why it is small: a few hundred kilobytes for a run whose state is several gigabytes. It identifies the program and the data, records a handful of numbers describing the machine, and makes a promise, at chosen points, of what the result should look like. The data itself must still be available.

A second computer reads the receipt, redoes the work step by step, and compares. If every promise holds, the recomputed results agree with the recorded account at those points. If one does not, the receipt says where. The second computer needs none of the original hardware. It needs the receipt, the program, the data, and time.

What we found

The first obstacle was the machine’s own arithmetic. A processor built for speed can add numbers in an order chosen for the hardware, and that order changes the answer. For the operations we studied, it was possible to recover the order from the machine’s outputs. What emerged followed a textbook pattern. Once we had written it down, a second computer could follow it to the last digit.

That let us write down what a machine would produce before renting it, then rent it and compare. We did this on four processors across three different designs, committing each prediction to a public record first. All four agreed with what had been written. A run of three hundred steps, written down in advance, matched the machine that later ran it.

Two smaller findings came out of the same work, and both were surprises. In the training configuration we examined, a setting left on by default reduced the precision of a third of the arithmetic. Routine checks had not exposed it. And the random numbers drawn at the start of training differed between the processors we tested, even with the same seed. Fixing a seed alone does not promise the same starting point on another machine.