Make the edit.
Check the claim.
Edit a small program. Check whether your change keeps its behavior.
Follow the steps below, then try the example.
Same result.
For every 32-bit input.
Running time can change.How can we prove that? ↓
How your edit gets checked.
You enter two programs
An original program and your proposed edit.
We build two Wasm files
We convert the code to Wasm text. Jad’s assembler makes the binary files.
AI writes a proof attempt
It tries to prove that your two functions give the same result for every input.
Lean checks the proof
It checks the AI’s argument and ties it to the exact Wasm files.
Replay and download
The server replays the proof through Lean’s kernel. You can download and recheck it.
Try any edit using x, constants, +, − and ×. Each pair gets a new proof attempt. Lean must accept it before we report equivalence.
AI-written part: prove the calculations are equal
This is the short Lean script the AI wrote for your edit. It is included in the complete file below.
For example, intro x means “take any input.” simp only […] expands the program definitions into calculations. ring uses algebra to build a proof that those calculations are equal. Lean checks that proof.
Complete Lean file: includes the AI-written part
This file includes the AI’s script above, checks that both program descriptions match the exact Wasm files, and connects the calculations to Jad’s Wasm execution rules.
These are two views of the same proof. Before Lean accepts the complete file, it is a proof attempt. A successful result means Lean checked and replayed the complete proof.
Read the checker log
A fresh proof.
For your exact edit.
The AI tries to prove your two functions return the same result for every 32-bit input. It can use algebra or a bit-vector solver. Lean checks the proof it produces.
1 Both program descriptions match the actual Wasm files.
2 The AI proves the two expressions give the same result for every input.
3 A checked helper connects that arithmetic to Jad’s actual Wasm execution rules.
Walk me through a new rewrite
Start with x * 2. Change it to x + x.
The AI writes a Lean proof attempt that these expressions are equal for every 32-bit input, including wrapping arithmetic. It can use a tactic such as ring to prove the identity.
Lean also checks that the two program descriptions encode the actual Wasm files. A helper theorem, proved against Jad’s execution rules, connects the arithmetic result to the executions of those exact function bodies.
This proof is specific to your pair. Your edit does not have to be the output of an existing optimizer pass.
What does generate.py do?
It prepares Proof.lean from a fixed template. It inserts both exact binaries, their proposed program descriptions, and the proof steps written by the AI.
The AI supplies the argument that the two expressions are equal for every input. The template adds the byte checks, module validity checks and connection to Jad’s execution rules. Lean checks the complete proof.
The script does not decide whether the edit is correct. A wrong argument or a program description that does not match its file must fail.
How do we know Lean has the right programs?
Each program description starts as a proposal. Lean proves that Jad’s encoder produces the exact original and edited Wasm files, byte for byte. It also checks that both modules are valid.
The small PureExpr.lean helper proves that our arithmetic expressions execute according to Jad’s Wasm small-step rules. It covers reading the input, constants, addition, subtraction and multiplication. You can download and check that helper too.
Jad’s library also has a decoder soundness proof. This proof path connects the descriptions to the binaries through the encoder checks above.
Is the AI writing a proof? Is there a solver?
Yes. The AI writes a small Lean tactic script for this exact pair. For example: introduce an arbitrary input, expand the expression definitions, then prove the equality with ring or bv_decide.
ring proves algebraic identities. bv_decide can use a SAT solver for fixed-width integers. Both produce proof steps or certificates that Lean checks. A solver’s success message alone is not accepted.
The AI has a bounded set of Lean proof commands. It can attempt new combinations of +, − and ×; it does not choose from a list of certified optimizer passes.
Where does checking happen? Why does it take time?
The browser runs the Wasm examples. The proof is prepared and checked on our demo server; Cloudflare hosts the website and forwards the request.
Jad’s compiled library and the proved execution helper are reused. Each edit gets a new proof about its exact bytes and arithmetic. Lean checks that proof, inspects its axioms and replays it.
Time depends on the edit and the proof method. Some proof attempts fail or reach the time limit. The result shows separate times for Lean and replay.
What do the three possible results mean?
Lean checked equivalence. Both exact Wasm files encode valid modules. Their compute function bodies evaluate to the same 32-bit result for every 32-bit input under Jad’s execution rules. The store and frame stay unchanged.
Different outputs found. Running the Wasm in the browser found an input with different answers. This is an execution counterexample.
Not established. The proof attempt failed or timed out. This does not establish whether the programs are equivalent.
Exact formal claim, supported input and trust boundaries
The chosen spec is LiveDemoProof.binaries_same_result: exact binary encodings, two valid modules, and actual Core.Steps executions of both first function bodies to the same i32 value for every i32 input. Executions preserve store and frame, under the closed host at every numerical profile.
This is a pure function-body execution spec. It does not claim full ExportEquiv, module instantiation equivalence, or equal timing and resource use.
The input UI supports one uint32_t compute(uint32_t x) function with constants, parentheses, addition, subtraction and multiplication. It defines wrapping i32 arithmetic. It is not a full ISO C frontend. The proof begins at the Wasm bytes and does not verify the C-style conversion.
The AI’s proof is an instance-specific equality over BitVec 32. The template uses Jad’s encodeModule?_sound and validate_sound, plus our helper’s execution theorem proved from his Core.Step rules. A failed attempt or timeout is “not established.” Browser counterexamples are labeled separately.
The proof uses public Silmaril revision 915988226ecd61a4862be0fadfdec89497592306, Lean 4.35.0-rc4, and only propext, Classical.choice, Quot.sound. No sorry, native_decide, custom arithmetic-checker fallback or new axioms are accepted. The library’s machine model, Lean toolchain, native runtime and I/O are trust boundaries.
The native tools run in bounded containers without network access. The checker can serve one native job at a time. A busy or unavailable service does not imply the programs differ.
Download Proof.lean, PureExpr.lean and the recheck instructions to compile them against the pinned public library. The check record includes the binary hashes, exact claim, checker log, allowed axioms, object hash, library revision and elapsed time.