Less work.
Same price.
A loop adds up an order. Can we replace it with one calculation?
Edit the code. Let AI write the argument. Let Lean check it.
Same price.
For every input.
and return the price specified below.How can we prove that? ↓
Code → Wasm → proof → check.
- 1
You edit a C program
Keep the price. Change how we calculate it.
- 2
We compile both versions
Clang builds two real Wasm files.
- 3
AI writes a proof attempt
It states what stays true in each loop and proves both versions meet the price rule.
- 4
Lean checks the argument
Jad’s verified decoder ties it to the exact files. His execution rules cover the loops and calls.
- 5
Replay and download
A separate kernel replay checks the proof object. Failed attempts go back to AI, up to three tries.
The AI must supply the missing reasoning. A loop needs an invariant: a fact that holds before and after each repeat. Lean checks that fact and that the loop finishes.
Each item costs 12 cents. Apply a 25% discount. Add a fee: 2 cents for an even item count, 3 for an odd count. Return 0 for orders over 1,000 items.
price = 9 × items + 2 + (items & 1)3 items → 30¢ · 4 items → 38¢Lean feedback sent back to AI
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.
Complete Lean proof file
The generated file adds the exact bytes, decoder checks and final execution statements around the AI’s argument. Lean checks the complete file. Before it passes, it is a proof attempt.
Read the checker log
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.