Watch the code
become a proof.
Edit C. Inspect the Wasm. Watch AI write a Lean proof.
Then watch Lean check it.
Try a preset or make your own edit. The claim stays fixed:
both programs must return the right price for every input.
The fixed rule 9¢ per item after discount + 2¢ fee. Add 1¢ for odd orders. How does that work? ↓
Start at 12¢ per item. Apply a 25% discount. Add 2¢ for an even item count, 3¢ for an odd count. Return 0 for orders over 1,000 items. Arithmetic uses unsigned 32-bit values.
price(n) = n ≤ 1000 ? 9 × n + 2 + (n & 1) : 03 items → 30¢. 4 items → 38¢. The proof must cover every input, including the bounds.
Edit C
The left program uses a loop. Change the right program. Both must meet the fixed price rule.
Start with “Build & inspect” to explore without calling AI. “Watch the proof” runs the whole process.
Your compiled files will appear here.
Edit the C, then build it. You can inspect the instructions, binary bytes and LLVM intermediate code.
Linking builds the file. It does not prove equivalence.
A / Original
B / Your edit
The proof starts at the Wasm bytes.
Build the C to see how those bytes become input for Jad’s Lean execution rules.
Unchecked preview. Lean will check the exact bytes and the completed proof together.
A / Lean input
B / Lean input
What am I looking at?
Bytes contains the real file. Locals lists its local variable types. Body describes its instructions using Jad’s Lean definitions.
Names such as originalAnn0 refer to loop annotations the AI must supply next. This preview is not yet a checked Lean file. The complete file will include those annotations and a decoder equality check, which Lean must accept.
The Python reader proposes this representation. It is not trusted to decode correctly: Jad’s verified decoder checks it against the exact bytes inside Lean.
Watch the missing argument get written.
AI must explain each loop and prove the price rule for both compiled programs. Click “Watch the proof” to start.
This is the model’s actual output as it arrives. It is a proof attempt until Lean accepts it. Private model reasoning is not shown.
What are these proof tools?
wasm_vc turns the instructions and loop annotations into obligations. The AI must show that each invariant starts true, stays true, gives the right answer on exit, and has a decreasing quantity that proves termination.
ring proves polynomial identities, such as 12*i + 12 = 12*(i+1). omega proves arithmetic bounds and facts about division and remainders. bv_omega connects fixed-width arithmetic to integer facts. These tools build proofs that Lean checks.
The AI cannot grade its own work.
Once its argument is complete, the server adds the exact files and fixed claim. Lean checks the whole file.
These checks run in one Lean job. They turn green together only after the job and its axiom audit pass.
The decoder and metadata checks must match both binary files.
WaitingBoth functions must finish and return the fixed price.
WaitingNo sorry or unapproved axioms. Only the three standard axioms.
WaitingThe complete Lean file being checked
The AI writes the annotations and program-specific proof steps. The template fixes the claim, embeds the exact bytes and connects the argument to Jad’s execution rules.
Actual checker output
Check the proof object again.
After Lean accepts the source, a separate kernel replay checks its compiled proof object. Both steps must pass.
The demo accepts equivalence only after the byte checks, proof, axiom audit and replay pass. You can download the proof and exact binaries below.
What the AI argued
These explanations describe the attempt. The result above says whether Lean accepted it.
AI-written invariants and Lean proof steps
The AI writes a fact for each loop, a quantity that must decrease, and Lean steps that prove the required obligations.
Every repeat.
Every input.
A few test runs cannot prove the edit works for every input. A loop invariant lets us reason about any repeat, without running them all.
1 At the start: the counter and total are zero.
2 After each repeat: the total still matches the number of items counted.
3 At the end: the total gives the required price. The counter cannot run forever.
Show me the loop argument in plain words
After counting i items, the total is 12 × i. That is the invariant.
It holds at zero items. One repeat adds 12 to the total and 1 to the counter, so it still holds. When the counter reaches n, the total is 12 × n.
The number of items left decreases each time, so the loop finishes. With at most 1,000 items, the discount calculation cannot overflow. Paying three quarters of 12 cents gives 9 cents per item.
Clang may move the multiplication by 3 into the loop, so the actual Wasm invariant can use 36 × i and divide by 4 at the end. The AI has to follow those actual instructions.
For the per-item discount edit, Clang precomputes the price but keeps a counting loop. Its invariant records the saved price and the counter bound; the proof must still show the loop stops.
What is new from Jad’s work?
This uses his newer program verifier: loop rules, a sound verification-condition generator, function-call rules and a verified Wasm decoder.
The verifier turns the program and the proposed invariant into proof obligations. Lean must prove the invariant starts true, stays true, gives the right answer on exit, and has a decreasing quantity that establishes termination.
This replaces the earlier expression-only demo. The full Wasm model is broader than the automatic proof path used here.
Is AI writing the whole proof?
AI writes the parts that depend on your edit: loop invariants, decreasing quantities and Lean proof steps for each program. It receives worked tactic examples, sees Lean’s errors, and can revise its attempt.
A fixed template states the price rule and exact files, then connects the new proofs to Jad’s execution rules. Keeping the claim fixed stops the AI from weakening it to make the job easier.
generate.py prepares that file. It does not decide whether the edit is correct. Lean makes that decision.
What are ring, bv_omega and omega?
They are Lean tactics: tools that build proofs.
ring checks algebra such as 12 × i + 12 = 12 × (i + 1). It expands and collects terms on both sides.
bv_omega converts fixed-width arithmetic to integer facts. omega builds proofs about bounds, constant multiplication, division and remainders. Bit-level facts, such as an even/odd test, can be reduced to those facts. Lean checks every proof.
Can I try a new rewrite?
Yes. Edit either C function. It does not have to match a preset or an existing optimizer pass. Both must still meet the fixed price rule.
This demo accepts one i32 input and result, local variables, integer arithmetic, branches and up to two loops. Calls, memory access, floating point and many other instructions are outside this proof path. Unsupported code gets an explicit error.
An equivalent edit can still be too hard for the current agent or time limit. “Not established” means no accepted proof was found.
Where does checking happen? What can I share?
The browser runs the Wasm examples. Clang, AI requests and Lean checking run through the server. Jad’s compiled library is reused; each edit gets a new proof.
You can download the proof source, helper, exact Wasm files, checker log and all attempts. The newer library is currently private. Independent rechecking needs access to that pinned source and its small lint-only patch.
The proof starts at the Wasm bytes. It does not prove Clang itself is correct, full module loading, or equal speed and memory use.
Exact formal claim and trust boundaries
LiveDemoProof.binaries_same_result checks that Jad’s decoder reads the exact two binaries as the annotated function bodies. It proves actual Core.Steps executions of both function calls to LiveDemo.price n for every i32 input, under any numerical profile and host, in the one-function instances built by the helper. Both return and preserve their stores. return_values_unique uses Jad’s determinism bridge to show that every returning execution agrees.
Separate checked metadata establishes the i32 → i32 type, absence of imports and the compute export. This is a function-call theorem. It does not prove full module instantiation, full ExportEquiv, C compiler correctness or equal resource use. Browser execution is a separate test.
Private Silmaril revision fc6be8f5e6f6de4c7795776842608dc9795c728f, with lint-only fixes; Lean 4.35.0-rc4. Only standard propext, Classical.choice, Quot.sound axioms are accepted. No sorry, native_decide or unproved SMT facts. The library model, toolchain and I/O are trust boundaries.
Native jobs use containers with no network, read-only libraries, and time and resource limits. A failed, busy or unavailable checker establishes no equivalence claim.
Explore existing public proofs: SHA-256 executable · Proved bugs. These reference examples do not generate new AI proofs.