A figure you can re-run

Every chart you have ever read asked you to trust it. A picture is not evidence: it is a claim that some data, put through some computation, came out looking like this. You are almost never given either one. This figure is different. It ships as a program, its input, and a receipt, and your browser just re-derived every plotted value in exact integer arithmetic and checked them against that receipt. If one number were off by one unit, the badge below would be red.

Coherence energy of a disagreement. A system does one thing; a model of it says something else. The energy cost of that gap, in units of k_BT, is the information distance between them. It is exactly zero where the model tells the truth, and it climbs steeply as the model gets confident about the wrong thing. Three models are shown, each certain of a different answer.

CHECKING 0 values re-derived 0 divergences in 0 ms

CHECKING independent JavaScript evaluator

What is bound	Recomputed on your machine

Try to break it

Both boxes are live. Edit the program or the grid however you like, press Re-run and verify, and watch what happens. The figure will redraw from whatever you typed, because it is drawn from the computation rather than from a stored image. The receipt will refuse it, because the receipt was written before you touched anything.

coherence_energy_native.cl the program, compiled to the WebAssembly running above

the second implementation editable: break it and watch them disagree

grid.json the input

receipt.json coherence-proof/v1, minted before publication

What actually happened when this page loaded

The program is coherence_energy_native.cl, written in Coherence Language and compiled to WebAssembly by our compiler. Its source was hashed and matched against source.cl_sha256, and the compiled module against model_commitment, so the receipt binds both the program and the binary your browser actually ran.
The input grid was hashed and matched against input.input_sha256.
Every plotted value was computed by that WebAssembly module, in signed 64-bit integer fixed point with 24 fractional bits and division truncating toward zero. No floating point took part in any plotted number.
A second, independently written program was evaluated by a JavaScript interpreter and had to produce all 0 values identically. It is not the source of the figure; it exists to disagree if either implementation is wrong.
The results were canonically encoded and hashed into a single commitment, and the whole claim was rebuilt and compared to proof_sha256.

The same program, on six backends, including the GPU. Before publication the compiler ran its own equivalence gate and required bit-identical results from every backend that would accept the program: c_native, interp, loovm, python_cpu, wasm, wgsl-i64-gpu. The WebAssembly rung of that ladder is the one running in front of you.

The rung that had to be built. The compiler's GPU lane declined this program, because it recognises integer sum-reductions and this is a nested loop computing a logarithm. Refusing was correct for that lane, and it would have been a poor place to stop: nothing about the arithmetic is beyond a GPU. Integer math is exact on every device. What WebGPU lacks is 64-bit integers, so a 64-bit fixed-point kernel has nowhere to land.

That gap is now closed. Sixty-four-bit integers are emulated as pairs of 32-bit words, an approach already used elsewhere in the stack, and the one primitive nobody had written was division: a multiply and a shift give you a*b/2^k, but not a/b. A restoring long division now sits in that library, checked on real hardware against arbitrary-precision integers. The functional then runs on the GPU and produces all 381 values identically, zeros included. Five independent implementations agree on every one: this program compiled to WebAssembly, a second program evaluated by a JavaScript interpreter, a Python evaluator, the compiler's native and virtual-machine backends, and now a graphics card.

Why integers here. Naive floating point is not reproducible: reorder a sum and the last bits move, which is fine for a picture and fatal for a claim. That much is well known. What is less known is that it is fixable. Every IEEE-754 double is exactly an integer times a power of two, so a dot product's true value can be accumulated with zero rounding in a wide integer and rounded once at the end. The result is the correctly rounded double, and because that value is unique, there is nothing left for summation order, fused multiply-add or parallel scheduling to change. Our compiler ships that, and it agrees bit for bit between Python and JavaScript. You can watch it happen in Float, Made Exact, where shuffling the terms of one dot product makes ordinary arithmetic give eleven different answers and exact accumulation give one. So float sums are not the problem.

What is still genuinely off limits is transcendental functions. No two platforms' libraries agree on the last bit of a logarithm, and unlike a sum there is no accumulation trick that makes them, so we hold that lane permanently closed rather than ship an answer that changes between machines. This figure needs a logarithm for every one of its points. That is the actual reason it computes in integers, all the way down to a series expansion for the logarithm itself: not because float cannot be made exact, but because this particular function is the one place where it cannot. Every intermediate is checked to stay inside signed 64 bits, because a value that quietly outgrew that range would still agree between two arbitrary-precision languages and then disagree with a re-run on hardware that wraps.

What this does and does not claim. The claim is reproducibility: these plotted integers are exactly what this program produces from this input, on any machine, forever. It is not a claim that the fixed-point series equals the real-valued function to infinite precision. It does not, and it does not pretend to: the integer logarithm here sits within about 6 × 10^-7 of the true value, which is the honest cost of refusing to use floats. What is exact is the zero, and the reproduction.

Independent implementations. The receipt was minted by a Python parser and evaluator; your browser re-derived it with a different parser and a different evaluator written in JavaScript. Two implementations in two languages agreeing on all 0 values is the property worth publishing. One implementation agreeing with itself would prove nothing at all.

Take it with you

This page reads nothing from the network. Save the folder and it keeps verifying, offline, forever, with no server to ask and nobody to trust. The program is coherence_energy_native.cl and the module built from it is coherence_energy.wasm; both ship beside this page. clwasm.js loads the module, clint.js and cl2wgsl.js are the second implementation, and sha256.js and coherence_verify.js are byte-identical to the open verifier in the Coherence Proof Fabric, which is what lets a reader check this receipt with software we did not write for this page.

You do not have to take our hashing on faith either. Run sha256sum on coherence_energy_native.cl and on coherence_energy.wasm: they are source.cl_sha256 and model_commitment in the receipt above, and this page recomputed both in your browser before it drew anything. Text hashes are taken with newlines normalised to line feeds, so a copy some editor rewrote still checks out; the module is hashed as raw bytes.