One Core, Three Systems

• SIOS is three distinct systems: our cloud (marketplace and key authority), the organisation's own on-premises server (installs studios, issues per-seat keys, holds data, runs inference), and the end-user workstation (runs the SIOS shell).
• The security-critical code is one shared Rust substrate linked directly by all three tiers. No reimplementation per tier, so an auditor and the release gates review one surface instead of three.
• The stack is fixed by internal standard: Rust primary everywhere with no unsafe code in the substrate, TypeScript and React for UI only, Tauri for the desktop client, Python offline only, plus one sealed GPU appliance.
• We claim a memory-safe core, not a memory-safe client end to end. The C, C++ and CUDA compute engines are isolated as supervised, ABI-guarded, loopback-bound sidecars that never enter the trust boundary.

Three systems, three jobs, one authority chain

SIOS is not one program wearing three hats. It is three distinct systems, and it helps to be precise about what each one does.

The first is our own cloud. It is the marketplace, and it is the authority that mints an organisation's master key. That is the only role our cloud plays in the trust chain: it issues the root of an organisation's entitlement, and nothing about a customer's data or inference passes through it.

The second is the organisation's own server, running on the customer's premises. It installs studios, issues per-seat keys to the organisation's people, holds the data, and runs the inference. Everything that matters operationally happens here, on hardware the customer controls, air-gap capable and offline by default.

The third is the end-user workstation, which runs the SIOS shell. This is where a person actually works, and where a per-seat key is verified before anything runs.

So the trust chain has a shape: our cloud mints, the customer's server issues, the workstation verifies. Mint, issue, verify. Three tiers, three responsibilities, one continuous chain of entitlement.

Why write the security code once

Here is the core of it. The audit ledger, the signing, the licence verification and the hardware attestation are written once, as a single shared Rust substrate, and linked directly by all three tiers. There is no per-tier reimplementation.

The reason is not to save typing. It is that a security control implemented separately in three places is three separate things that can be wrong, and three separate things an attacker can probe for the weakest of the three. If the cloud signs one way and the workstation verifies in a subtly different reimplementation, the gap between those two implementations is exactly where a defect lives. You do not find that gap by reading either side on its own.

When the code that mints a key in our cloud is the same code that verifies it on the workstation, there is no gap to find, because there is no second implementation. The mint side and the verify side are the same logic compiled into different tiers.

The practical payoff is review. An auditor reviews one surface. The release gates run against one surface. Fix a flaw once and every tier inherits the fix in the next build. Three trust surfaces would mean three reviews, three chances to diverge, and three places to keep in sync forever. One is simply a smaller thing to get right, and a smaller thing to keep right.

The stack is fixed, not chosen per project

The way you keep a single substrate coherent across three tiers is to stop re-deciding the stack every time. Ours is fixed by an internal standard.

Rust is primary across all three tiers, and the shared substrate forbids unsafe code outright. That is the load-bearing decision: the code that carries the trust boundary is written in a language that removes whole classes of memory defect at compile time, and the substrate holds itself to the stricter bar of no unsafe escapes.

TypeScript and React are used for the user interface, and only the user interface. The desktop client is built on Tauri, so the shell is a native application driving that Rust core rather than a browser pretending to be one. Python is used offline only, alongside one sealed, vendored GPU appliance. Bindings for outside developers are generated from the Rust crates rather than hand-written, so the interface other people build against is derived from the real thing and cannot drift away from it.

None of this is exotic. It is deliberately boring, because a trust boundary you share across three systems is the last place you want novelty.

The honest boundary: a memory-safe core, not a memory-safe client

I want to be exact here, because this is where it is tempting to overclaim and I will not.

What is memory-safe is the Rust core. It is not the whole operating-system process end to end. The compute engines that sit behind the inference boundary are large C, C++ and CUDA codebases, and no amount of wishing turns them into safe Rust.

So we do not link them into the trust boundary. We isolate them as supervised, ABI-guarded, loopback-bound sidecars. They run under supervision, they talk across a defined ABI rather than sharing our address space, they are bound to loopback rather than exposed, and they are never part of the code that mints, issues or verifies.

The claim, stated plainly, is a memory-safe core, not a memory-safe client end to end. The trust boundary is Rust and holds itself to that standard. The compute engines are a known, contained, deliberately fenced-off exception. I would rather state that distinction precisely than let the word memory-safe carry more weight than it has earned.

Gating the supply chain, and the release gates

A single shared substrate is only as trustworthy as what it is built from, so the dependency tree is gated in continuous integration on every change.

Every change runs formatting, linting with warnings treated as errors, and the full test suite. It runs a supply-chain policy scan: security advisories, an allow-list of permissive licences, and a rule that crates come only from approved sources. And it emits a CycloneDX software bill of materials, so what actually went into a build is recorded, not assumed.

Above that sits a fixed set of release gates that every release must pass. They cover production readiness, design, SOC 2 readiness, security, IP and licensing, and AI governance. A release does not ship because it compiles and someone is in a hurry. It ships because it has cleared the same fixed set of gates every release before it cleared.

This is the unglamorous half of writing the code once. One substrate is easier to gate honestly than three, and the gates are where the honesty is enforced rather than merely intended.

Where this sits in our filed estate

We hold 104 filed patent applications carrying 2,340 claims in total, all patent-pending. Our strategy is deliberate: we patent the mechanism, not the model. We do not seek protection on any particular AI system. We seek it on how sovereignty, auditability, licensing and orchestration are enforced, and structural decisions of the kind described in this article sit squarely on that terrain.

We do not disclose model lineage, and we do not stake our position on any single algorithm. The value is in the enforcement architecture: the rules by which a key is minted, issued and verified, the way an audit record is made tamper-evident, the way a licence is bound to hardware. That is what the applications describe, and it is why the architecture matters more than any one component inside it.

Questions people ask

Why not just implement the security code separately in each tier, tuned to each environment?

Because three implementations are three things to trust, three things to review, and three places for a subtle divergence to become a vulnerability. The gap between a cloud signer and a workstation verifier written separately is exactly where defects hide. Writing the code once removes the gap entirely, since there is no second implementation to disagree with the first.

What exactly is shared across the three tiers?

The security-critical code: the audit ledger, the signing, the licence verification and the hardware attestation. These live in one shared Rust substrate that all three tiers link directly. The user interface, which is TypeScript and React, is not shared in this way. Only the trust-bearing core is single-sourced.

Is the whole SIOS client memory-safe?

No, and we do not claim it is. The Rust core is memory-safe and the substrate forbids unsafe code, but the compute engines behind the inference boundary are large C, C++ and CUDA codebases. We isolate those as supervised, ABI-guarded, loopback-bound sidecars that are never linked into the trust boundary. The honest claim is a memory-safe core, not a memory-safe client end to end.

Does the customer's data or inference ever pass through your cloud?

No. Our cloud is the marketplace and the authority that mints an organisation's master key, and that is the whole of its role in the trust chain. The organisation's own on-premises server holds the data and runs the inference. Everything operational happens on hardware the customer controls, offline by default and air-gap capable.

How do you stop a bad or mislicensed dependency getting into the shared core?

Every change is gated in continuous integration: formatting, linting with warnings as errors, the full test suite, a supply-chain policy scan covering advisories, an allow-list of permissive licences and crates-only sources, and a CycloneDX software bill of materials. On top of that, every release must clear a fixed set of gates spanning production readiness, design, SOC 2 readiness, security, IP and licensing, and AI governance.

What are the honest limits of the audit ledger's guarantees?

The ledger is tamper-evident and cryptographically verifiable relative to a signed checkpoint held where an attacker cannot rewrite it. That is a strong and specific claim, and it has an open boundary: an attacker can still delete the file or refuse to run the verifier. Those actions are conspicuous. What is ruled out is silent, unnoticed alteration of the record.