Home / Platform / Security

Security is a property
of the engine.

Not a layer added on top. There is no query language, so there is nothing to inject. There is no anonymous path and no silent rewrite. Each installation creates its own post-quantum root of trust, and the engine refuses to start if its chain of trust does not verify.

What the engine guarantees

Six properties, enforced in the engine itself.

⌀

Nothing to inject

No query language reaches the engine. Requests are structured operations on the hierarchy, checked before they run.

⚿

Separate roots of trust

Separate post-quantum roots for the platform, users, devices and data. Each root is created in a ceremony, split into sealed pieces, signs exactly one thing and goes offline.

⛨

Keys kept apart

Separate key-keeper processes hold the only signing keys. The engine checks the whole chain before it opens a connection.

⇆

Post-quantum transport

TLS 1.3 with hybrid post-quantum key exchange between every component that talks to the engine.

▣

Groups, per knowledge area

Access is granted per knowledge area, to groups only. Every refusal is audited — a case or a client can be sealed off by the engine.

✓

A signed install

Every installed file and every source file is listed in a manifest signed with a post-quantum key. A swapped binary will not start.

0
device certificate life
0
user certificate life
0
data certificate life
0
anonymous paths into the engine
Identity

One user, one device,
one verified pairing.

A person is identified by a user identity bound to a specific device. A device is accepted only after its certificate is checked out of band, and access then follows the groups that person belongs to — never an individual exception hidden in a table.

Every write is checked against the ledger before it is accepted, and every decision about access is itself recorded.

Ceremony

The installation creates its roots, splits them into sealed pieces and takes them offline.

Enrolment

A device presents its certificate; it is verified out of band before it is trusted.

Sign-in

User and device together — short-lived certificates, renewed automatically.

Every request

Chain verified, group checked against the knowledge area, the decision audited.

Federation without a centre

Several complete installations.
No centre to fail.

A hospital, a regulator and an insurer each run their own engine, keys, ledger and knowledge areas. They pair by device-certificate exchange checked out of band. Only signed changes travel, and only from the areas each chooses to share — clinical and personal areas never leave. If a site goes dark the others carry on, and it reconciles when it rejoins.

Pair by certificate

Every installation knows exactly who its partners are, verified out of band.

Share by area

Each owner chooses which knowledge areas travel. Nothing else ever leaves.

Attested changes

Only signed, attested changes are exchanged — and each is checked before it is applied.

Need to question several owners without exchanging data at all? See the Virtual View →

PULSE · signed, sealed, peer to peer

A social network with no central database.

Each person runs their own AtomicDB node and nodes exchange directly. Every message is signed twice — classical and post-quantum — and sealed for one recipient with a post-quantum pair key. Nothing flows until the recipient accepts a specific device.

0
checks passed across two machines (measured)
0
message text found in the clear on disk
0
signatures on every message
0
combined hardening score on the development host

Refuses the attacks

Tampered, replayed and forged messages were all refused in the measured run.

Device-accepted

A conversation opens only after the recipient accepts the sender's specific device.

Designed, not yet built

Tor and LoRa delivery, and Presence Pay. Shown here so no one mistakes them for shipped features.

Early PULSE recordings

Silent early cuts from the first build. The narrated security walkthrough is at the top of this page.

Read further

Security papers