How I came to the solution
1. The ground shifting
AI was everywhere. It was the new gold rush, and it came with a great deal of uncertainty, for many people and for me. The pace was relentless. For the first time in thirty years of technology, I felt I couldn't keep up.
2. Choosing to become a player
I didn't want the ground to keep shifting beneath me. I wanted to find my own way of taking part: to become a player, not a spectator.
I wanted something specific: the leverage that lets one person, a sole trader, build something that behaves like a company, with agents doing the work of a team.
And I had to protect myself against the churn. Models and tools were becoming commodities, replaced every few months. So I made a rule: rent the churn, and build the thing that lasts.
3. Borrowing what I already knew
Everyone was talking about an “agentic operating system”, but there was nothing to go by. So I did what a network engineer does: I broke the problem into layers, using ideas I had lived with for thirty years.
The first idea was Linux. Linux can become a file server, a firewall or a web server, without rewriting Linux. So the platform would have a core that knows nothing about any application or industry. Because it knows nothing about them, it never has to be rewritten for them.
The second was the layered network model. Each layer does one job, and things plug in. A browser can specialise in doing one thing brilliantly, and nobody says the system is all over the place, because a firewall sits right beside it. That told me I could build focused applications on one platform without it becoming a mess.
The third was Microsoft Word. A bank uses a word processor. A hospital uses a word processor. It isn't a banking app or a hospital app. It's a document platform. That's how I thought about applications: a general capability that each industry uses in its own way.
4. What I built: three runtimes, each wrapping the next
I built it in three layers.
At the centre is the factory runtime. It's the core: it runs any application declared as data, whether a course, a book or a regulated workflow, and it knows nothing about what any of them are for.
Around it is the execution runtime. It does the actual work: it runs the agent loop, calls the model through a replaceable harness, resolves credentials, governs cost, and records every run in a tamper-evident ledger. That ledger is the execution evidence: what the agent did.
Around both is the governance runtime. It decides whether a consequential action is allowed at all, and it produces governance evidence: which rule allowed it, which checks were trusted, who approved it, and whether that can be proven.
The key design decision is that the dependency runs one way. The governance runtime knows about the platform; the platform never knows about governance. So an ordinary application runs exactly as before, and a regulated one inherits governance without the core changing.
5. The test that proved it
Then came the question that mattered. Regulated industries (health, finance, government and others) each seemed to need their own governed AI platform. I wanted one governed platform, specialised for each industry by declaring its rules in a domain pack, not by rebuilding.
So I set a test before building the second domain: it must need zero new abstractions in the core. Health came first. Then finance, and the core didn't change. Then I repeated the experiment eight more times, choosing industries with different regulatory philosophies: legal, insurance, pharmaceuticals, aviation, industrial safety, government, human resources, critical infrastructure.
Ten domains ran on the same core. The eight added after the first two changed no existing file at all. Anyone can check that in the repository history.
6. The trust problem
Getting the architecture right led straight to the real problem: trust.
AI, by its nature, can invent things and say them convincingly. I had already met this building certification courses: every claim had to be grounded in a source and verified. But regulated work asks a harder question than “is this answer accurate?”
An agent can draft a clinical explanation or a financial research brief. That's capability. But capability is not authority. Before that output leaves the system, someone must be able to answer: which rule was in force, exactly which version? Which checks were applied, and why should those checks be trusted? Who approved it, and did that person actually hold the authority at that moment? And can all of that be proven afterwards?
7. The gap I found
So I studied what already existed, and there's a lot of excellent work.
Policy engines can deny actions by default, and one cloud agent gateway already applies that to tool calls. Guardrails check content. Approval workflows let a human pause and approve. Assurance cases justify systems. Supply-chain tools sign and verify artifacts. Governance frameworks and the EU AI Act say what must exist.
But each stops at a different boundary. Guardrail verdicts are advisory and don't control release. Approvals are usually granted by any logged-in user, with nothing proving they held the licence to approve. Nobody asks whether the automated checker itself has been measured and is still trustworthy. And governance frameworks describe what must exist, not how a system enforces it for each decision.
In what I surveyed, nothing joined them into one path that decides, at the moment an agent tries to act, whether it may, and proves why.
8. What we did
So we joined them. Every consequential release passes through one deny-by-default path, and it starts closed. The proposed action is classified by consequence. The exact version of the policy is evaluated. The checkers' findings must be signed, and each checker must hold a current, measured qualification. Required human approval is bound to a fresh check of that person's identity and licence at the moment they approve. Only then is a single-use permit issued, for the exact bytes being released. Every outcome, including every refusal, is signed, chained to the one before it, and anchored to storage that cannot be overwritten.
And one record serves everyone: the regulator, the auditor, the person asking “why was this allowed?”, and the machine that verifies it.
It's synthesis, not invention. Every layer has mature precedent. What we didn't find was their composition into one enforced path, per decision.
9. What happened
We didn't just design it. We measured it.
The same governed path ran against a real, single-tenant hardware security module in FIPS mode and against real write-once storage: 854,100 governed decisions over a continuous 24 hours, with zero failed batches and no slowdown from the first hour to the last.
We cut the network to the signing hardware mid-run, and the next decision was refused. We revoked write access to the storage, and the release was aborted before a single byte left. It fails closed.
An independent tool from the software-supply-chain security community verified our signed attestations, and rejected tampered ones.
10. What we believe
I didn't set out to design a governance architecture. This is what we did, this is what happened, and so this is what we believe.
AI should evolve the way operating systems did. Don't rebuild governance inside every AI application. Build it once, as infrastructure, and let every application inherit it.
Governance shouldn't be a witness that writes a report after the event. For consequential actions, it should be a condition of the action.
And humans remain accountable. Automation amplifies judgment; it never removes responsibility.
11. What we offer
We offer a governed AI platform, specialised by domain packs, for organisations where AI actions must be authorised and provable: healthcare, finance, government and other regulated work.
Instead of a separate AI governance project for every application, you inherit one authority path and declare your domain's rules. And for partners who know a regulated domain deeply, we offer the foundation to build their own domain packs on.
Not smarter AI. Trustworthy action, with proof.