SMARTHAUSThe Mathematically Governed AI Fabric
Investors ↗ Twenty minutes
UCPUniversal Control PlaneIn daily use

Access is not authority.

Every system you own decides whether an identity may ever do a class of thing. None of them decides whether this action should happen, right now, at this scope, for this long, and on whose say-so. This is where that decision is made, bounded, recorded — and withdrawn.

StatusIn daily use on our own engineering
SeamThe action boundary
RunsLocal-first · 0 cloud round trips
TiersLoge · Forge · Enterprise
SAME ACCESS · THREE DECISIONS “delete branch main” AGENT ACCESSIDENTITY AUTHORITYUCP EFFECT has access identity allowed never executed A PERSON WHAT THE GATE DECIDES, FOR THIS ACTION THIS ACTIONdelete branch main RIGHT NOWrefused AT THIS SCOPEnone granted FOR THIS LONGnone granted ON WHOSE SAY-SOrule set 3f9a, pinned LEDGER · EACH RECEIPT CARRIES THE HASH OF THE ONE BEFORE 9c2eprev 1b07ADMITTEDedit README.mdrule set 3f9a 4d81prev 9c2eALLOW ONCEsend mail to a customerDana e3a0prev 4d81REFUSEDdelete branch mainnever executed ACCESS: MAY THIS IDENTITY EVER? · AUTHORITY: THIS ACTION, NOW?
5
decision behaviours demonstrated on a real machine — plus two clients through one plane, and the joined record
2
different AI clients governed through one plane at once
3
grant lifetimes — once, this session, until revoked
0
cloud round trips in the decision path

The hard part of enterprise AI is no longer the model. It is that an agent now holds a live credential. It can read the repository, send the mail, change the record, spend the money — and in most organisations the only thing between intent and effect is a paragraph in a policy document that no running system has ever read.

Your identity platform will not close that gap, because it answers a different question. It grants a principal the standing ability to use a capability. It is not in the path of a particular action, it does not know that this branch deletion is unusual, and it cannot ask anyone at the moment of consequence. Worse, your agent is not a principal in it at all — it is borrowing a person's. In the access log, the agent and the employee are the same actor.

Authority is the missing object. Not “may this identity ever do this”, but “is this action authorised, at this scope, until when, by whom — and can I prove it afterwards, and take it back.”

The position, in one sentence

Every other system governs access. UCP governs authority.

Gateways sell interception. Identity platforms sell entitlement. Guardrails sell filtering. All three are real products and none of them sells authority — which is why nothing in your estate can currently answer the only question that matters after an incident: who authorised that, how far did the authorisation reach, and when did it lapse.

Authority has a lifetime

Once, this session, or until revoked — bound to the exact action and the exact scope by hash. Revoking sends the next matching request back for a fresh look. A gateway policy is on or off; it has no lifetime.

Authority has an author

Every grant carries the identity of the person who gave it, so the agent and the human are separate actors in the record rather than one borrowed identity.

Authority leaves a receipt that chains

Each entry carries the hash of the entry before it and pins the rule set by digest, so the rule you land on is provably the rule that fired. No product in this market signs or chains an agent-decision record.

And the boundary, stated first rather than extracted later: no gate can govern a credential it does not hold. Coverage follows where the tokens live, which is why the first conversation in a deployment is about credentials rather than about us.

Licensing

Three tiers. The decision path is identical in all three.

What changes is who sets the rules and where the evidence is answerable.

Loge

Individual

The default at first run. A person governing their own agents on their own machine.

Forge

Team

The administered tier. Enrolment, saved permission scope and revocation across a working group.

Enterprise

Organisation

Central policy authority across the estate.

The problem

Your estate governs access. Your agents act on authority.

Everyone can tell you what happened. Nobody can tell you what will happen.

Almost everywhere, a policy is text. It is asserted, not proved.

01

You cannot know what it does until it does it

A tested policy behaved on the cases somebody thought of. It says nothing about the case nobody thought of.

02

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

A file was edited, the meaning moved, and nothing anywhere 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.

Why that matters to whoever signs

Every control in your organisation ends with somebody putting their name to it.

For AI, that name currently sits on top of a paragraph. An attestation, a control narrative, a model risk sign-off, a board assurance statement — each one is a person asserting that something behaves a particular way. For everything else in the estate they can produce a system behind the assertion.

01

The effect

A branch was deleted, a payment left, a record changed.

02

The decision

What was requested, with which exact arguments, at what scope, and whether it executed.

03

The rule that fired

Pinned by digest at the moment it decided.

04

Its proof

The calculus, the Lean proof manifest, the invariants, the scorecard, the oracle's result.

05

The person

The sentence they wrote in English, locked and hashed, with their name on it.

Because each receipt carries the hash of the receipt before it, the file cannot be tidied afterwards. That is the difference between describing a control and producing one.

The test

Switch it off and the agent cannot act.

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.

That is the whole distinction, and it is checkable in four seconds rather than argued. A system that describes who should decide produces paperwork. A system that decides produces effects — this ran, this did not, this waited for a named person.

Which is also why we are upstream of the platforms that keep the register rather than competing with them. Their file is better if we exist, because for the first time there is a system behind the assertion instead of a paragraph.

How it works

Authority, granted and bounded in one pass.

Nothing here depends on the model behaving well — the path is identical whether the agent is careful or confused. Three outcomes are possible: the rules authorise it and it runs, the rules refuse and it does not, or the rules say this shape of action needs a person. Only the third reaches anybody.

Local decision path · 0 cloud round trips
01RequestAn agent asks to do something consequential, with its exact arguments.
02ScopeWhat it is reaching for, hashed, so the record cannot drift from the act.
03Rule setPinned by digest at this moment — not named, pinned.
04DecideA proved domain rule answers, or a named person is asked.
05BoundOnce, this session, or until revoked — bound to that action and that scope.
06ReceiptWritten to a hash-chained ledger that stays with you.

Most requests are settled by the rules already in force. People are interrupted for the exceptions — the difference between governance and approval fatigue.

Concretely

What it is.

A control plane, not a dashboard

Actions pass through it. It is in the path of the effect, which is what makes a refusal mean something.

Local-first by architecture

The authority that decides runs on the machine where the work happens. Nothing has to leave before you decide it should.

One control point for everything in reach

Agents, connected tool servers, rules, policies, installed packages, models, runtime state, health checks and the ledger of decisions already made.

Systems on the far side of the gate are the ones where mistakes cost money: bank and treasury, payments, travel and expense, contracts, customer records, mail and messaging.

How a rule is made

A rule you can check, not a rule you are asked to trust.

The rules UCP enforces are constructed and proved upstream, by the Mathematical Autopsy Engine. Skip a phase and the package does not exist — enforced by the recertification record inside every brick, not by anyone remembering.

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

What a rule can be aligned to

Anything you can define precisely enough to decide.

Law and regulation, named down to the provision rather than the statute. Supervisory and industry standards. Contractual obligations. And your own internal policy — the rules nobody outside the company has heard of and everybody inside it is judged against.

The constraint is not the subject matter, it is the shape. The rule has to reduce to a bounded decision: a threshold, an arithmetic test, a bounded state machine, an admission or classification decision. A disclosure limit, a lending decision, a sanctions screen, an approval workflow, a spending cap, a retention window — each is a bounded decision wearing business clothes.

Aligned means aligned to the clause it names, and explicit about where it stops. Our data-minimisation candidate names GDPR Article 5(1)(c), then states in machine-readable form that the domain is reduced to a single boolean, that it proves an admission decision over that boolean and nothing further, and that purpose-binding, field-level necessity, retention and proportionality are not proved.

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

Full detail on the method: how a rule is made →

Evidence

Five decision behaviours, and two things around them.

The first five rows are decisions the gate makes. The last two are not decisions — one is two different AI clients governed through one plane at once, the other is the joined record. Everything in this group has been exercised on a real machine with real AI clients connected, and the records are in the ledger. Everything in the second group is current work. We keep the two apart on purpose — a demonstration is worth something only if the line is visible.

DemonstratedAllow onceA human approval followed by the actual file execution. Both sides recorded.
DemonstratedDenyThe refusal recorded and the effect did not occur.
DemonstratedSaved allow, reusedA remembered decision applied to the next matching request without re-prompting.
DemonstratedRevocationAfter revoking, the same request returned to a fresh human review instead of inheriting the saved answer.
DemonstratedAsk every timeExecution blocked until answered, and the session preference went inactive on disconnect.
Also shownTwo clients, one planeA desktop coding tool and a command-line coding agent ran through one control plane at the same time, each recognised as itself. One reconnected on its own after a restart.
Also shownThe joined recordThe decision and the execution appear as one entry in the ledger, and in the file you export from it.

How to test it yourself

Twenty minutes, your machine, your coding agent, our software.

01

Connect your own agent

Whatever your engineers already use, pointed at the local broker.

02

Ask it to do something real

Something that writes, not something that reads.

03

Deny it

Then confirm in your own environment that the effect did not occur.

04

Read the ledger

And check that the request, the decision and the execution are the same record.

That is the honest test, and it is the one we ask people to run. We will set it up on your machine and stay on the call while your own engineer tries to break it.

Hard questions

The objections you arrived with.

Every technical buyer asks the same things, and they are good questions. Here they are, answered without pretending the trade-offs do not exist.

“Won't this bury my people in approvals?”

No, because people are not in the loop by default. The rules are.

Every request is evaluated against policy, entitlement and any saved decision that already covers it, and three things can happen: the rules allow it and it runs, the rules refuse it and it does not, or the rules say this particular shape of action needs a person. Only the third case reaches anybody.

So the honest answer to “how many interruptions” is: exactly as many as your own rules ask for. If a team is drowning in prompts, that is a statement about their rule set, not about the gate.

Expect the first week to be noisier than the tenth. That is when the saved decisions get established. It is worth planning for rather than discovering.

“We already have identity and access management.”

You do, and it is answering a different question. Identity systems decide whether a principal may ever use a capability. They are not in the path of a particular action, they do not know that this branch deletion is unusual, and they cannot ask a person at the moment of consequence.

The part that usually lands hardest: your agent is not a principal in your identity system. It is borrowing a person's. In the access log the agent and the employee are the same actor, so the question “did Dana delete that branch, or did the thing acting as Dana delete it” has no answer there. It has an answer here.

These compose rather than compete. The entitlement your identity system issues is an input to the decision, not a replacement for it.

“What stops an agent from going around it?”

Two different answers, and the second one is the one that matters.

If the plane is not running, the connected client has no tool path at all. The failure mode is that the agent cannot act, not that it acts unwatched. Unknown actions, malformed rules and scopes that cannot be resolved all refuse rather than proceed. A gate that fails open is decoration.

But no gate can govern a credential it does not hold. An agent with its own standing token and a network connection can always call an API directly, past anything. That is true of every product in this category, and no vendor in it can honestly claim otherwise. The answer is not a cleverer gate; it is that agents stop holding standing credentials of their own, and reach systems through the plane instead.

In the fabric

Where UCP sits, and what it hands on.

UCP is the seam at the action boundary: the rules it enforces are constructed and proved upstream, and the record it writes is the one an auditor walks back through.

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 the effect

A refusal means the effect never happens. Admission is bounded by scope and lifetime, and both are in the record.

To the ledger

A decision receipt pinning the rule set by digest, carrying the hash of the receipt before it.

To MAE

The join. The decision pins a rule; the rule carries its Receipt of Truth; the receipt carries the 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

Twenty minutes, on your own machine.

Connect your own coding agent, ask it to do something that writes, deny it, verify in your own environment that nothing happened, then read the ledger.

Book the twenty minutes