Your hardest capability.
Proven, and yours to run.
MGR is the custom runtime we build for your highest-stakes AI capability — its rules written in math, proven by construction, then compiled into governed, deterministic software. We build it with MAE during the engagement; you keep the runtime, the source, and the proofs — running on your own infrastructure.
You can't prove your high-stakes AI meets its spec — and risk won't sign off on a guess.
That's failures F1, F3 and F5 — no proof the capability meets its spec, tests that drift out of reality, and no record behind a single decision. MGR closes them by construction: the rules are proven in math before the runtime ships, and the proofs ship inside it. See the six failures →
Most software is tested into shape — you write it, then hope your tests catch what's wrong. MGR inverts that. In the engagement we write the capability's governing rules in math, prove them, and only then compile the runtime. It is correct because it cannot be otherwise.
What you receive is the runtime — usually embedded in the application you already run, sometimes a complete application of its own — with the source, the proofs, and a verification record your auditor can re-run on a clean machine, without us.
MGR · From proof to runtime
Three places MGR earns its keep.
Get a dosing capability out of pilot.
A medication-dosing capability is stuck because no one can prove its bounds. MGR ships it as a proven runtime inside your EHR — correct by construction.
Ship a pricing engine risk will sign.
A high-stakes pricing engine that risk won't approve on a guess. MGR delivers it proven by construction, with a verification record they can re-run.
Enforce a constraint that can't be violated.
A capability that must never cross its rules. MGR carries the proofs inside the runtime — it is correct because it cannot be otherwise.
What MGR actually is, in a list.
Proven by construction
The invariants aren't tests it might pass — they're properties the runtime carries. It is correct because it cannot be otherwise, not because a check happened to run.
Yours to keep
Source, runtime, and proofs are yours. No license leash on the capability, no dependency on SMARTHAUS to run it after we hand it over.
Runs on your infrastructure
Your compute, your keys, your network. MGR runs where your application runs — nothing phones home to a SMARTHAUS cloud.
Deterministic
Same input, same action, every time. Run under SAID and the inference underneath is replayable too — the whole path is reproducible.
Governed at runtime
Under UCP, every action MGR takes passes its proven contract before it fires. Admit or refuse — with a signed receipt either way.
Re-verifiable, by anyone
The proofs ship as an executable verification record your auditor can re-run on the open-source Lean 4 toolchain — without us in the room.
Usually a runtime. Sometimes the whole application.
MGR ships in the shape your capability needs — most often a proven runtime embedded in software you already run; when the capability is the product, a complete standalone application. Either way it's yours, on your infrastructure.
Embedded in your app
The usual shape — a proven component that drops into the software you already run, governing one high-stakes capability.
Standalone, when it's the product
When the high-stakes capability is the whole thing, MGR ships as a complete, proven application of its own.
Governed at runtime
MGR runs under UCP's invariant set; every action passes its proven contract before it fires, with a receipt.
Evidence, fleet-wide
Every MGR reports verification evidence up to OC, where your auditor and board can re-run the proofs.