Proof, not benchmarks
A faster benchmark is a hint. A checked proof is evidence an auditor can accept.
Isomer rewrites a codebase for speed and footprint, then refuses any change it cannot machine-check against the original — and signs the proof.
12float dot_product(const float* w,13 const float* x, int n) {14 float acc = 0.f;15 for (int i = 0; i < n; i++)16 acc += w[i] * x[i];14 float acc = dot_simd(w, x, n);17 return clamp(acc, lo, hi);18}
Isomer proposes many optimizations and tries to prove each one equivalent to the original. Only the ones that pass an independent checker reach your diff. The one it can’t prove is dropped — it never becomes a change you have to second-guess.
Every accepted change ships with a signed certificate: the source and optimized hashes, the checked equivalence proof, and the standard clause it satisfies. It is produced where the change is made, so the evidence exists before anyone asks for it.
A faster benchmark is a hint. A checked proof is evidence an auditor can accept.
Hand-written or model-generated, every line is preserved exactly and optimized under the same proof requirement.
Each verified transformation joins a growing library of transformation-and-proof pairs — so the set of changes Isomer can justify compounds over time.
Most tools generate a change and then test it. Isomer inverts the order: it will not surface an optimization unless it can first construct a proof of behavioral equivalence and have a separate checker verify it. The checker stays small and independent of the part that proposes changes, so trusting a result never means trusting the optimizer — only the proof.
No. A compiler optimizes within guarantees it already owns and leaves no artifact you can hand an auditor. Isomer works on your source, proposes higher-level changes, and attaches a proof and a certificate to each one, so the result is admissible evidence rather than a faster build you still have to defend.
It discards it. An optimization that cannot be shown equivalent is treated as a failure, not a suggestion. You only ever see changes that carry a proof the checker has already accepted.
Yes. Isomer makes no distinction between hand-written and model-generated code — both are preserved exactly and optimized under the same proof requirement. The code whose origin you trust least is where a machine-checked equivalence proof is worth the most.
It is being designed around the regimes where behavioral evidence is mandatory — DO-178C in avionics, IEC 62304 in medical devices, ISO 26262 in automotive — and the audit needs of core banking. The certificate references the clause a given optimization satisfies.
Isomer is an early concept from The Adjacent Possible. We’re building the proof-synthesis engine and the first verified transformation library, and we’re looking for avionics, medtech, automotive, and banking teams who already live by the standards.
Or write to [email protected]