A governed runtime that runs inside the software you ship.
You tell us what has to be governed. The engine constructs and proves the rule. The rule is sealed into a runtime, the runtime goes into your product, and it decides at the seam you declare — on your customer's infrastructure, where no console can reach. And it stays connected to Operations Center, so when the rule changes you do not ship a new version of your product.
If you build software and sell it, your controls stop at your own perimeter. The moment your product is installed on a customer's infrastructure, every gate and policy engine you rely on is on the wrong side of the line. You cannot say what your own software decided out there, and neither can they.
That is the seam this is for. Not a service they call, not a console somebody watches — a runtime inside your process, at a point you declare, that admits a sealed rule, activates it atomically, decides there, and emits a receipt both sides can read.
The foundation is standard. The rules are yours. That distinction is the product.
We do not hand you a toolkit and wish you luck, and we do not write a one-off for you either. The runtime is built, proved and signed; what gets made for your application is the rule that goes into it.
The position, in one sentence
Every other control in this market runs on infrastructure somebody can redeploy. This one runs where nobody can.
Four properties, each checkable in the released package rather than asserted here.
It decides in your process
An in-process component your build includes, invoked at the seam you declare. Not a network call, not a sidecar, nothing for your customer to operate.
It refuses what it cannot verify
The rule arrives content-addressed and signed. A missing digest, an unproved lemma binding, an obligation with no covering node, or an edge without its interface lemmas — each one stops the build rather than degrading it.
It will not run from a source tree
The package declares execution from a repository path as not allowed. It runs from a signed artifact root or it does not run.
The rule can change without you shipping
It stays connected to Operations Center. A re-proved rule reaches it where it is, inside software already installed somewhere you cannot redeploy.
If this delivery model sounds unfamiliar, it is not
It is how validated cryptographic modules have worked for twenty years.
A vendor gets a module validated once. Other vendors embed that validated module inside their own products, and the validation travels with it — the downstream product inherits the evidence without redoing the work. Regulated buyers already accept that arrangement.
This is the same shape with one difference that matters. A cryptographic module's certificate is a document from a laboratory. Ours is a machine-checkable receipt that walks back through the proof to the sentence a person wrote.
How an engagement runs
Five steps, and only the first one is yours.
You tell us what has to be governed
A clause you are answerable for, a limit inside your product, a decision your customers ask about.
The engine proves the rule
The stated intent is locked and hashed, then taken through the method until a kernel and an independent check both return go.
The rule is sealed into a runtime
Signed, content-addressed, carrying its proof, its invariants, its provenance and a statement of what it does not cover.
Your build includes it
At the seam you declare. It decides there.
The rule changes without the product changing
Through Operations Center, which is the reason this works rather than being a one-off.
Available to contract now. The foundation is released; what is made for you is the rule.
The problem
Your controls stop at your own perimeter.
This is not a gap in anybody's product. It is a property of where those products live.
Switch it off and the agent cannot act.
That is the test we would apply to anything in this category. Not a gap in the record, not a missing report — the action does not occur, because the thing that was switched off was in the path rather than beside it. A system that describes who should decide produces paperwork. A system that decides produces effects.
In a cloud you control
Excellent for your own agents, and structurally unable to reach software running on somebody else's infrastructure.
On a machine you manage
Good for your employees' laptops, and not installable on a customer's estate.
In your identity system
Fine for principals you issue credentials to, and silent about what your shipped product does once it is out there.
Each is correct for its own problem. None of them is on the far side of the sale.
If you ship software
The question arrives at you, and every control you built is on the wrong side of the boundary to answer it.
Your product contains AI parts. Those parts make decisions on your customer's data, on your customer's infrastructure, under your brand. You cannot say what your own software decided, and neither can they. That is not a tooling gap. It is where the tools are.
The regulated version of the same problem: your customer must demonstrate control over AI acting on their data, and the AI in question is inside a product they bought from you. Today the honest answer is a contract clause.
Small enough to embed
It runs inside your process, at a point you choose, not as a service somebody has to operate.
Fed by artifacts, not configuration
Rules arrive sealed and signed, and admission verifies them rather than trusting a file.
Atomic about what is active
Half an activation is not an activation, and the runtime must say which rule set was in force.
Answerable to both sides
The receipt has to mean something to you and to your customer — not a log line in your own format.
What it enforces
Seven contracts, and it refuses on any of them.
The released runtime validates a chain of evidence before a rule is allowed to become active. Each of these is a refusal point, not a warning.
Intent
The locked, hashed sentence the whole chain descends from.
Formalisation
The formal statement derived from it.
Decomposition
The graph of nodes the rule breaks into, with its obligations.
Lemma set
The supporting facts, bound to the nodes that need them.
Kernel validation
A green Lean 4 result with its proof manifest.
Build plan
What is to be produced, and from what.
Receipt of Truth
The closure record, digest-pinned section by section.
Any one of the seven failing stops the candidate. There is no partial admission.
The check that does the most work
Every obligation must be covered by a node that exists, and every edge must carry its interface lemmas.
This is the part that makes a decomposition honest. It is easy to write a graph that looks complete; it is not possible to pass this one without every stated obligation mapping to a real node, and without the join between any two nodes carrying the facts that make the join sound.
It also pins the canonicalisation rule exactly — stable JSON, UTF-8, sorted keys — so two parties hashing the same graph get the same digest, or the runtime refuses.
Three things it will not decide for itself
All eight of its invariants are marked fail-closed.
Admission by an upstream authority
The guard that approves a locked intent has to have said admit. The runtime does not take that decision.
A green kernel result
Not a claim of one — the manifest, checked.
An explicit operator approval
A named human has to have approved the apply. The runtime refuses to treat its own validation as authorisation.
What is standard and what is yours
Three templates. That is the whole customisation surface.
A locked intent, a decomposition, and a Receipt of Truth. You bring the use case as a decomposition with your obligations attached; the runtime, the proof machinery and the refusal behaviour are the same for everyone.
This is why it is a product line rather than a practice. The foundation does not get rewritten per customer. The rule does.
MGE
A separate product, and the clearest proof that it is separate.
People assume these are two names for one thing, or that one supersedes the other. Neither is true, and one piece of evidence settles it.
MGE governs the coding agents that build MGR.
The rules directory in the MGR repository says so in its own words: those files are compiled and enforced by the Mathematical Governance Engine, and agents are instructed to route every decision through it. One is the tool you use to build the other safely. That is complementarity demonstrated rather than argued.
Why they cannot be merged
Three differences, and each one alone would be enough.
Opposite rule sources
MGE compiles text files a developer edits and reloads them on save. MGR admits immutable, hash-pinned, kernel-proved artifacts and refuses to execute from a source tree at all.
Opposite positions
MGE is a separate process a caller reaches over the local network. MGR is in-process, inside the host, at a declared seam.
Different buyers
MGE's buyer governs their own developers. MGR's buyer governs their own product, running on somebody else's infrastructure.
Neither imports the other, in either direction.
What MGE is good at
Its fail-closed behaviour is the most literal in our estate.
One rule that will not compile blocks every request — it does not skip the bad rule and carry on. An approval that cannot be signed is rewritten into a denial rather than returned unsigned. Measured: a hundred runs, zero disagreements, one result hash, decisions under two milliseconds.
Evidence
Released, signed, and registered in the control plane.
Checkable in the package rather than asserted here.
What we would want from a first engagement
One rule inside one product, at one declared seam.
Not a platform decision and not a pilot programme. A clause you are already answerable for, taken through the method, sealed into a runtime, embedded at a point you choose, with the receipt readable by you and by your customer.
And then the part that proves the model: change the clause, and see the rule reach it without your product shipping.
Hard questions
What a head of engineering asks first.
Answered as we would answer them in the room.
“So it is a library we have to integrate?”
Your build includes a component. We do the part that is hard. The surface your code touches at the declared seam is small and ordinary. What is not ordinary, and what you are not doing yourself, is the artifact format, the admission checks, the atomicity of activation, the proof chain behind the rule, and a receipt your customer will accept.
We do not lead by calling it a toolkit, because a toolkit implies you supply the governing logic. You supply the requirement. We supply the rule and the thing that enforces it.
“Why would we embed a third party's control in our product?”
Because the alternative is building the same thing, and the hard part is not the enforcement. It is the evidence chain that makes the enforcement mean something to somebody who did not write it.
“What happens when the rule changes?”
Nothing ships. That is the point of the whole arrangement. The clause moves, the engine rebuilds and re-proves the rule, and Operations Center delivers it to every runtime holding the old one — including the ones inside software installed on infrastructure you have no access to.
Nothing is retrained. Nothing is redeployed. No customer is asked to take an upgrade because a regulator changed a threshold. This is the one capability here we would call genuinely difficult to copy, because it needs the proving engine, the runtime and the delivery plane to be one company's work.
“Is this actually available?”
Yes. The runtime is released, signed and registered. What gets built for you is the rule.
It is not something you download and evaluate alone, and we would rather say that plainly than dress a services motion as a self-serve product. The engagement is short and concrete: one clause, one seam, one runtime, and a rule change demonstrated at the end of it.
In the fabric
The third seam, and the only one outside your building.
Two of our seams govern AI inside your estate. This one governs AI inside software you sell.
One rule, three places
A rule proved once should be enforceable wherever it needs to hold.
The proving engine produces a sealed artifact carrying the proof, the invariants, the provenance, the locked English sentence it came from and a statement of what it does not cover. The same artifact is what the output seam enforces, what the action gate admits, and what an embedded runtime admits inside your product.
How a changed rule reaches it
Operations Center is not a console here. It is the delivery mechanism.
Every runtime in the fabric stays connected to it, including one embedded inside software running on infrastructure you will never have access to. When a rule changes, that connection is how the new, re-proved rule arrives — with enrolment, heartbeat, rollout, rollback, kill-switch, key rotation and revocation all working today.
Without it, an embedded rule would be frozen at the version you shipped. With it, the rule moves and the product does not.
The thesis
Mathematics as the nervous system of AI.
Everything here descends from one argument: that the integrating substrate for artificial intelligence should be mathematics itself — not another orchestration layer, not a better prompt, and not a policy document.
Each part of a modern AI system works. The joins between them do not. Vision, language, planning and retrieval are each remarkable and they are integrated through hand-built pipelines and brute-force scaling. The thesis proposes a shared mathematical space that components write into and read from through operations defined once and behaving the same way for all of them — a nervous system rather than a bundle of wires.
Guarantees become measurable. Every property claimed has a quantity attached. Measure it and either the implementation holds or it is broken; there is no third answer.
The foundation is reusable across customers. The calculus, the construction engine, the control plane and the receipts are common. Your rules, connectors, integrations and authority model are yours.
The ladder, in order
Each rung was built from the one before it.
That order is why the components share a foundation instead of being a suite assembled after the fact, and it is why a refusal at the action boundary can be traced back through a proof to a sentence somebody wrote.
The paper
Openly licensed, so you can check the argument.
Open
Mathematics as the Nervous System of AI: A Unified Field Operator Framework for Distributed Cognition. Philip Siniscalchi, v9, 27 August 2026, CC-BY-4.0.
Falsifiable
It separates conformance — does the implementation obey the mathematics it claims — from superiority over alternatives, and refuses to let the first stand in for the second.
Bounded
No claims about consciousness or sentience. The biological analogies are engineering inspiration, not identity claims. Theoretical extensions are labelled as a roadmap, never as capability.
Start at one seam
Bring one clause. See it reach your product without a release.
Tell us what has to be governed inside what you ship. We prove the rule, seal it into the runtime, embed it at your seam — then change the rule and watch it arrive without your product shipping.