The engine you build
proven software with.
Mathematical Autopsy is the discipline; MAE is the engine you run it with — write the rules in math, prove them, generate the code. What you build is a Mathematically Governed Runtime (MGR): custom, deterministic, proven by construction. Run MAE in your own pipeline, or have us build it with you.
You can't prove your AI meets its spec — and what passed in January quietly fails by June.
That's failures F1, F3 and F5 — no proof your AI meets its spec, tests that drift out of reality, and no record behind a single decision. MAE closes them at the source: it proves the rules in math before a line of your runtime ships, and bakes those proofs into the Mathematically Governed Runtime you deploy. See the six failures →
The Mathematical Autopsy framework is how we open up your high-stakes capability and locate, in math, what it must never do. MAE is the engine that runs that method: it turns your rules into math, proves them rigorously, and compiles the result into your Mathematically Governed Runtime — governed and deterministic by construction.
What you receive is the MGR — not the engine that built it — and the proofs travel with it. When your spec changes, we rebuild and re-prove in MAE, then ship the new runtime. Correct by construction, with a verification record your auditor can re-run.
MAE · Build pipeline
Three places MAE earns its keep.
Build a proven capability in-house.
Your team wants to ship a high-stakes capability they can prove. MAE runs the Mathematical Autopsy method in your CI — write the rules in math, prove them, compile.
Gate unproven code out of the build.
A capability must be proven before it ships. MAE won't let code through the gate until it has been proven correct.
Re-prove when the spec changes.
A rule changes and the runtime has to change with it. MAE rebuilds and re-proves before the new runtime ships — drift never gets a foothold.
What MAE actually does, in a list.
Turns intent into proven code
Your rules go in; a proven, ready-to-run component comes out. The same rigor we use to diagnose a system, run forward to build one.
Bakes the proofs into the runtime
The proven rules aren't a test your runtime might pass — they're properties it carries by construction. It is correct because it cannot be otherwise. When a rule changes, MAE rebuilds and re-proves before the new runtime ships.
Keeps the rules current
Your rules live as versioned, signed records. When a business rule changes, the proven version changes with it — and every call from that point forward is held to the new one.
Hands you evidence a person can read
For every rule, a plain record your engineers can read, your auditor can re-check, and your regulator can sign off on. Proof you can hand to a person.
Feeds receipts and Operation Center
Every build emits verification evidence — what was proven, what passed, what was refused — packaged for Operation Center. Every Decision Receipt the runtime later writes inherits it.
Templates from the open Mathematical Autopsy method
MAE is the engine that runs the publicly-documented Mathematical Autopsy framework on your capability. Your team can read the framework and audit the proofs. Nothing is hidden behind a vendor brand.
The build path, in your environment.
During the Applied Mathematical Autopsy engagement, MAE runs in the build path — embedded in your CI, on your engineers' machines, with findings reviewable from Operation Center. The Mathematically Governed Runtime it produces is what ships into your application.
Inside your CI / promotion path
MAE runs in your build infrastructure. Every release runs through the same proofs before it ships.
Desktop, for engineers
Engineers write rules, run the checks, and clear the gates locally before they ever push.
The runtime, org-managed
The MGR that MAE produces runs under your org's rules as policy, reporting verification evidence up to Operation Center across the fleet.
Findings, on the go
Native iOS / Android. Approve or deny remediation, review alerts, voice-query engagement status while you're between meetings.
The method, the engine, and what you keep.
Mathematical Autopsy (MA) is the discipline — how SMARTHAUS engineers think and code. MAE is the engine that runs it. The Mathematically Governed Runtime (MGR) is what comes out: proven, deterministic, and yours — with a verification record anyone can re-run.