SMARTHAUSThe Mathematically Governed AI Fabric
Investors ↗ Twenty minutes
MAEMathematical Autopsy EngineAvailable now

A rule is an opinion until something refuses to build it.

This is where a sentence in English becomes a rule that can refuse. Constructed rather than written, proved in a kernel, checked back against the intent it came from, and sealed with all of its evidence inside. If any phase fails, there is no package.

StatusSealed runtime, in use
SeamWhere the rules are made
ChecksA Lean 4 kernel and an independent oracle
Both must sayGO
ONE SEALED · ONE REFUSED 1 “Refunds above 500 need a second approver.” 2 “Refunds must be reasonable.” INTENTa person's sentence, locked and hashedlocked · 91b0 THEOREMproposed from the intent“reasonable” has no bound · refused KERNELlemmas, invariants, proofs · Lean 4not reached ORACLEcases from the contract, never the rulenot reached SEALsigned, with its evidence insidenot reached 1 · SEALED PACKAGE the rule and its proofinvariants · scorecardthe locked sentencewhat it does not prove 2 · REFUSED NO PACKAGE nothing was built
9
phases, each one gating the next
2
independent checks — the prover and the oracle — and both must say GO
6
machine-checked invariants in the package shipping today
1
declaration, in every package, of what it does not prove

Every organisation already has its rules. They are in a policy document, a control narrative, a regulation, a contract, or somebody's head. They are written in English, they are approved by people, and no running system has ever read one of them.

So the rule gets translated. Someone writes a condition in a configuration file, a paragraph in a system prompt, or a classifier trained to recognise the thing. That translation is where governance quietly stops being governance: nothing proves the translation is faithful, nothing states what it fails to cover, and nothing checks afterwards that the artifact still does what the sentence said.

MAE removes the translation step as an act of interpretation and makes it an act of construction. A stated intent is locked and hashed. A theorem is proposed from it and validated by a Lean kernel, then lemmas, then invariants, then the proofs, then an executable notebook. An independent oracle then asks the only question that matters — does the executable rule still behave the way the sentence said — using cases drawn from the contract and never from the artifact.

What leaves the engine is not a rule. It is a rule plus everything needed to defend it two years later, including a machine-readable statement of what it does not prove.

The position, in one sentence

The rest of this field proves artifacts that somebody already wrote.

MAE constructs the artifact and proves it — then checks the result back against the human sentence it came from. Formal verification is a real and mature industry, and it starts where your code already exists. MAE starts one step earlier, at a stated intent, and ends one step later, at a sealed package that arrives in production with its proof attached.

Nine phases, enforced rather than documented

Intent lock, theorem, kernel validation, lemmas, invariants, proofs, notebook, the Oracle at phase eight, and the sealed runtime at phase nine. Every package carries a recertification record showing each phase present and green. A package with a missing phase does not build.

The loop closes at the Oracle

A proof tells you the specification is sound. It does not tell you the artifact still behaves like it. The oracle's cases come from the contract, never from the artifact, and the artifact is forbidden from grading itself — a schema constraint, not a convention.

The package states its own boundary

Every rule declares, in machine-readable form, what it does not prove. A proof that does not state its boundary is not a proof. It is a reassurance.

And what MAE is not

It is a lab and a proving tool. It is not a runtime, and it does not write your software.

MAE constructs and proves rules. It does not sit in the path of your traffic — that is the action gate's job — and it is not a code generator. Its generator engine is not built, and we do not claim it is.

We say this on the first screen rather than the last because the fastest way to lose a technical buyer is to let them discover a boundary you were hoping they would not ask about.

The problem

Everywhere else, a rule is text. It is asserted, not proved.

Three consequences follow, and they are the reason this company exists.

01

You cannot know what it does until it does it

A tested policy behaved on the cases somebody thought of.

02

You cannot prove the rule that fired is the rule you approved

A file was edited, the meaning moved, nothing announced it.

03

Nothing states what a policy does not cover

So scope gets assumed — and assumptions are where incidents live.

There is a sharper version of the third one. A large part of this market now uses a language model to judge whether an action is acceptable. That is a guessing machine supervising a guessing machine, and when it is wrong there is nothing underneath to catch it.

And it matters more now than it would have five years ago, because the author of the artifact is often a model. Tests written after a model's own code catch about 14% of faults; tests written from the specification catch about 25%. Implementation-derived invariants caught three bugs out of a hundred and one, and got two of those wrong.

The method

Nine phases. Skip one and the package does not exist.

Mathematical Autopsy is the method — a fixed sequence a rule must survive before it is allowed to exist. MAE is the software that runs it and refuses to skip a step.

The intent
Phase 1 · a person writes it in English, then locks it
→
A theorem, checked
Phases 2–3 · proposed from the intent; Lean 4 accepts or rejects
→
Lemmas, invariants
Phases 4–5 · the steps the proof needs, bounds for every input
→
The proofs
Phase 6 · written in Lean; a model may only propose
→
The notebook
Phase 7 · an executable form of the rule, run and recorded
The Oracle
Phase 8 · does the executable rule do what the sentence said? Cases from the contract, never from the rule
→
The sealed runtime
Phase 9 · extracted from the proved notebook, signed, pinned

Both the prover and the oracle must say GO, or there is no package.

Scope

What it can turn into a rule — and what it will not.

The subject matter is open. The shape is deliberately narrow, and the narrowness is what makes the proof possible.

It builds

Threshold and arithmetic decisions, bounded state machines, admission and classifier and monitor families, embedded control components, and compiled decision graphs. A disclosure limit, a lending decision, a sanctions screen, a seller's approval workflow — each is a bounded decision structure wearing business clothes.

It will not build

Arbitrary programs, unbounded processes, free-form formulas outside its typed language, or anything that reads the wall clock. We publish that list, because a tool that claims to do everything has told you nothing about what it does.

What comes out

The brick.

A rule leaves the engine as a signed package. The one shipping today carries the constructed calculus, a Lean 4 proof manifest, the proof itself, six machine-checked invariants, a scorecard, a conformance record, provenance, signatures over both payload and manifest, and a digest for every asset inside. The control plane refuses to admit it if any of that fails to check.

It also carries the Receipt of Truth: the proof result, the invariants, the scorecard, the conformance record, the provenance — and the locked natural-language intent the whole thing was derived from.

A proof that does not state its boundary is not a proof. It is a reassurance.

The Oracle

Does the executable rule do what the sentence said?

A proof tells you the specification is sound. It does not tell you that the executable rule still behaves like the specification. That step is where this industry relies on testing, and says so.

So we check it, in the only way worth anything: the cases are derived from the contract, never from the generated code, and the artifact is forbidden from grading itself — a schema constraint, not a convention. The prover and the oracle must both return GO. If either refuses, there is no package.

The limit, stated the way the receipt states it: this is finite scenario equality bounded by the declared oracle cases. It is evidence, not a universal refinement proof.

What is new, and what is not

This is the claim most likely to be challenged by someone who knows the field.

Not new

  • Oracles derived from a specification rather than an implementation — there were 317 papers on that by 2015.
  • Verification independence, which DO-178C has required for decades.
  • Back-to-back testing of a model against generated code, highly recommended under ISO 26262 at the higher safety levels.
  • Shipping evidence with an artifact, which is proof-carrying code from 1997.

Genuinely thin in the literature

  • Hash-locking the original human intent as the root of the chain — the least-populated part of the space.
  • Binding a proof result and an execution result into one signed receipt keyed to that intent, for which the attestation ecosystem has no predicate at all.
  • Making the oracle's independence a machine-checkable property — these scenarios came from the contract hash, not the artifact hash — rather than an organisational rule about which human wrote them.

None of the six steps is new. The composition, the gate semantics and the receipt are.

Evidence

What the engine has actually done.

Measured runs, not descriptions of runs.

Measured671 candidate rules, one runAcross nine regulated domains — banking, payments, insurance, markets, health, privacy, AI, software, and rules that cut across all of them — in a single deterministic campaign. None blocked, every route green.
MeasuredZero clock, network or randomnessNowhere in the run. The same campaign produces the same result every time, which is the part that matters when a rule has to be defended two years later.
MeasuredA real rule, end to endA trading notional cap taken through the method with a Receipt of Truth, an independent verifier and tamper tests.
MeasuredEleven kernel-checked theoremsBehind a governed transformer boundary, with no unproved steps in the proof.

Stated plainly: those 671 are proposed candidates, held rather than published. The run was a demonstration of the method, not a shipped rule set.

Bring your own clause

An afternoon, not a quarter.

A policy sentence from your own controls, taken through the method and handed back as a proved package with its receipt and its declared boundary. That is the test we ask people to run, because it is the one where the answer cannot be rehearsed.

Who else

Where they start, where they stop, and where we do.

Formal verification is a real and mature industry. We are not going to pretend otherwise, and the honest comparison is narrower and more interesting than a claim to have invented the field.

“Amazon already does formal methods for policy.”

They do, and they have done more real formal-methods work than anyone in this industry. Their policy language has a machine-verified evaluator with mechanised proofs. Their automated reasoning can decide whether one policy is more permissive than another.

Two things are true about it. What it proves is a property of an access policy — may this principal reach this resource. It does not prove a rule about the world: whether a disclosure is within minimum necessary, whether something counts as adverse action under Regulation B, whether a payee has been screened.

And there is no proof that the shipped engine matches the verified model — that link is covered by randomised differential testing. Design verified. Implementation tested against the verified design. That gap is the one the Oracle closes.

“Verification tools already exist.”

They start where your code already exists: here is a program, does it have this property. That is genuinely valuable and it is not what this is.

MAE starts one step earlier, at a stated intent, and ends one step later, at a sealed package that arrives in production with its proof attached. The artifact is constructed from the intent rather than proved after the fact.

“Everyone is putting AI into verification.”

They are, and we do the reverse. Every major verification vendor is putting AI into the verification flow this year — agentic test generation, copilots for coverage. None is putting verification around the AI.

It is the opposite architecture, not a feature gap.

In the fabric

Where MAE sits, and what it hands on.

MAE makes the rules that everything else enforces. It does not sit in the path of your traffic.

TAI
→
MAIA
→
CAIO
→
SAID
→
UCP
→
MGR
→
Effect

Beneath every step: RFS and NME hold state and meaning, and MAE on the Unified Calculus supplies the rules and their proofs.

The contract

What it promises the next component.

To UCP

A sealed, signed package the control plane refuses to admit unless every digest inside it checks.

To MGR

The same sealed artifact, admitted inside software you ship onward to your own customers.

To the auditor

The Receipt of Truth — the proof, the invariants, the scorecard, the provenance, and the locked sentence a person wrote.

Every component is a product in its own right and works without the others. The contract is what makes them compose when you want them to, not a dependency that makes you take all of it.

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.

Rung 01
The thesis
The origin.
Rung 02
Mathematical Autopsy
The method.
Rung 03
MAE
The engine that runs it.
Rung 04
Unified Calculus
The foundation it builds on.
Rung 05
The components
What you actually deploy.

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 you already have to defend.

We take it through the method and hand back a proved package with its receipt and a statement of exactly what it covers.

Book the twenty minutes