How it works · for architects and technical buyers
The architecture, in plain terms.
Accountable by construction. Owned end-to-end.
Most systems bolt accountability on after the fact — a log here, an audit there, a vendor's promise that it all behaved. We built the opposite. Every action is governed, stamped, and reconstructable before it is allowed to happen, and the record sits on a chain you can recompute yourself. The transport, firewall, and runtime underneath are ours — clean-room Rust that addresses the chain, not the operating system. Here is how the pieces fit.
Don't trust this description — open the proof and recompute it in your own browser
Patent-pending — U.S. Provisional 63/921,717
The four load-bearing ideas · start with what you can check
Two of the four ideas you can verify yourself.
None of these are features you switch on — they are structural, so the system cannot operate any other way. We begin with the two an architect can check directly: how every action is gated and stamped, and how the record stays tamper-evident on a chain you can recompute.
Governance is the first gate, not an afterthought.
Before any action runs, it passes through governance: is this allowed, by whom, under what authority, and can it be reconstructed later? If the answer to any of those is no, the action never happens. There is no privileged path that skips the gate — governance is wired into the only path requests can take.
Each permitted action is stamped at the moment it occurs — who, what, when, under which grant — so the record is written as the work happens, not assembled afterward when memories and logs have drifted apart.
Gated
Default-deny. An action is permitted only against an explicit grant — never by being already in motion.
Stamped
Who, what, when, and under which authority — recorded at the instant the action occurs.
Reconstructable
Every decision can be replayed from the record — the full chain of authority, end to end.
Chain-native: integrity is provable, not promised.
Records, access events, and changes don't live in a database someone can quietly edit. They live on an append-only WORM hash-chain — write-once, read-many — where every entry is bound to the one before it by a cryptographic hash. To alter the past you would have to recompute every hash that follows, and the discontinuity would be plain to anyone who checks.
That is the difference that matters to an architect: you don't have to believe a vendor's assurance that nothing was tampered with. You recompute the chain and the math either reconciles or it doesn't. Trust resolves to math, not to our word.
The same public verifier behind our proof page is the one anyone can run — there is no separate, private "real" log we keep to ourselves.
The four load-bearing ideas
Four decisions hold the whole system up.
None of them are features you turn on. They are structural — the system cannot operate any other way. That is what lets us say accountable by construction and mean it literally.
No OS, no ports, no sudo — built by us.
The system does not lean on the operating system's network stack. The transport, firewall, and runtime are clean-room Rust we wrote ourselves. Instead of opening OS ports and trusting whatever the host exposes, the system addresses the chain directly — capability-as-address, default-deny, governed grant. There are no general listening ports to scan, hijack, or misconfigure.
Read it as a security posture: a minimal attack surface and no dependence on the host OS's process and network model. The orb is self-contained — it carries its own transport, its own firewall, its own runtime — so the blast radius of a host-level compromise is far smaller than in a conventional port-and-service deployment.
Minimal surface
No general OS ports exposed inside the fabric — nothing to port-scan or reuse.
Clean-room Rust
Transport, firewall, and runtime are ours — memory-safe, auditable, no opaque third-party stack in the path.
Self-contained orb
The unit carries everything it needs, so it doesn't inherit the host OS's network and process risks.
Root of trust, extended toward silicon. Roadmap
Today the trust chain is rooted in software we control. The architecture is designed to extend that root of trust down to the hardware — hardware attestation that ties a running orb back to the silicon it runs on, so the verifiable chain reaches from the application all the way to the metal.
To be precise: this is on the roadmap, not shipped. We describe it as a direction the design already accommodates, not a capability you can verify in production today. When it ships, it ships with the same recompute-it-yourself proof as everything else.
The data moat · owned end-to-end
No third-party links in the trust chain.
A chain of trust is only as strong as its weakest borrowed link. Most platforms stitch together someone else's transport, someone else's runtime, someone else's database — each one an outside party you are quietly asking your customers to trust too. We own the stack firmware-to-app, so the trust chain has no handoffs to vendors we don't control.
Owning the vertical end-to-end is not about pride of authorship. It is what lets the trust chain be complete: from the application down, every link is one we built, can audit, and can prove — with no outside party you have to take on faith in the middle of it.
The whole point
Don't trust this description. Recompute the proof.
Everything above is a claim until you check it. So we built the check into the product: the same chain we describe here is one you can recompute, live, in your own browser — no account, no download, no taking our word for it.
Go deeper
The architecture is the proof. See it both ways.
Read the standard the architecture upholds, then recompute it yourself. The description and the math should agree — and you should never have to take that on trust.