Turn a policy you argue about into a rule the software can't break.
A written policy is a guess about behavior. MAE makes it provable: you state what must always be true as math, an assistant drafts the proof, the Lean 4 kernel checks it, and the proven rule compiles into the code as a constraint it cannot violate. This is how mathematically governed software gets built — same input, same output, by construction.
The engine that turns a policy you can argue about into a rule the software cannot break.
Turn a policy you argue about into a rule the code can’t break.
MAE compiles a plain-language rule into a proven constraint your software cannot violate. You state what must always be true, and it becomes part of the build instead of a guideline you hope holds.
You state what must always be true — a rule your risk or compliance team already owns.
An assistant drafts the proof; the public Lean 4 kernel checks it. If it doesn’t hold, it doesn’t compile.
The proven rule is compiled into the code as a constraint, not a guideline.
The build produces a sealed record proving the rule is sound and was built in.
Most teams write the policy in a document, then write code and test against it, and hope the tests caught everything.
MAE proves the rule first and compiles it in, so correctness is part of how the software is built — not something you test for afterward and hope.
Why it’s better: A rule that’s compiled-in and machine-checked can’t silently rot like a test suite, and anyone can re-check the proof in the public kernel. See how we build it →
The Mathematical Autopsy, run in your pipeline.
It is the inversion of how software is built today. Instead of writing code and then testing and hoping, you prove the math first and compile it in. MAE is that method as an engine, so your team builds proven software on your own code, not just ours.
Define intent as math
The rules a system can never violate are written as formal invariants, not prose policy sitting in a document.
Draft and check the proof
An AI proof-drafting assistant proposes the math, and the Lean 4 kernel checks it. If it does not hold, it does not compile.
Compile the rules in
The proven rules become constraints compiled into the code, part of how the software is built, not a layer bolted on top.
Runs on your code
The autopsy method runs inside your own build and review pipeline, against the software you are shipping.
Produces the Receipt of Truth
Notebook, scorecard, and invariant are hashed and sealed into the runtime, so the binary carries proof of its own origin. See it.
Powers MGR
The same engine builds your Mathematically Governed Runtime, your hardest capability, proven and yours to keep.
The rule is a proof they can re-check in the public Lean kernel, not a policy they have to take on trust.
Build it proven the first time.
Math first, code last. That ordering is the whole bet.