How it is built, and where to check it.
The architecture, the protocol, the cryptography and the embedded library under every product, with each claim's evidence in the source.
One engine, many clients.
Every product is a client of one engine: the phones, the headless client, the C library for equipment. The architecture.
Specified construction by construction.
The protocol, its known-answer vectors computed by the shipping code, and since 6 November 2026 a schema of every message the engine seals, which another implementation compiles: held to the engine field by field, and an example of each kind of message, encoded by the reference protobuf library, read back by the engine unchanged. A field number the schema has published keeps its meaning: a change that would give it another is refused before it is made. The protocol.
Post-quantum where a recording would be read later.
Every connection between a device and a relay is sealed by a hybrid key exchange of X25519 and ML-KEM-1024, with every frame after it sealed by ChaCha20-Poly1305, over Tor by default; identities are post-quantum key pairs made on the device. Between two Android phones on one network (measured on two emulators, not yet on real phones), the same channel is opened under a code one phone showed the other. What is still classical, and the plan for it, is listed in the post-quantum inventory in the source.
Which cryptographic claims are true, and how a false one survived, is kept in the open: Security and Limits.
The engine as a C library.
For Linux on x86_64 and 64-bit ARM, with a stable C interface: identity, pairing, sealed messages, radios, nets, orders, firmware trust, signed records and, since 4 November 2026, post-quantum channels over a maker’s own links, commands that need the platform’s own condition or a second person, a net’s reports read as one picture with their disagreements shown, its members’ positions and times checked against each other, and SAPIENT messages carried between paired devices. It can be used from C, from C++ and, since 5 November 2026, from Python. Developers.
Speak the standards already in use.
Since 4 November 2026 our library carries SAPIENT (BSI Flex 335 v2.0) messages, the interface between counter-drone sensors and the systems that fuse and task them, between paired devices, and a node’s identity is the device it was paired as; a task reaches a sensor or an effector only from a device granted to task it or an operator who holds the right to, within the organisation’s written policy, and a task can be made to need a second person’s approval of that exact task. A small gateway program connects an existing SAPIENT sensor and fusion node across a net without changing either. Not yet run against a real fusion node or the standard’s compliance harness.
The position format TAK clients speak, after SAPIENT.
What we measure, and what we got wrong.
The measurements behind every number, with dates, and the attacks we ran against our own defences. Research and audits.
No independent audit yet.
No independent third-party security audit has been done. What exists instead, and why it is not an audit: Trust.