Documentation
Documentation
These docs describe how Eidola works, what it commits to, and what it doesn’t yet defend against. They are written for a technical reader who wants to understand the design — and who, in turn, can vouch for it to less technical friends and family.
Start here
- Paradigm — How to think about Eidola. The user-sovereignty lens that everything else assumes.
- Privacy guarantees — Enumerated, durable commitments that a release officer signs against every release.
- Threat model — Who Eidola defends against, who it doesn’t, and what is left as residual trust.
Design pieces
- The client — Fail-safe by design, embedded trust root, per-handshake attestation.
- The server — Linked vs. unlinked surfaces, anonymous credentials, what runs in confidential compute.
- Inference upstream — Where models actually run, and how that layer is verified.
Release flow
- Releases — How a new client+server bundle becomes trustable. CI signature plus human attestation, both on the same transparency log.
- Trust root — The technical specification: what’s pinned at compile time, how schema versions work, how the verifier walks the chain.
What’s missing
- Known gaps — Every piece of the trust chain that is intentionally deferred, with what it would catch and what constrains it today.
Operations
- Infrastructure and vendors — The complete list of third parties that process data for Eidola, and exactly what each can see. Referenced by the privacy policy.
For contributors
Contributor-facing READMEs live alongside the code they describe. Start with the top-level README.md for the project landing page and dev setup, and releases/README.md for release-pipeline operations. AGENTS.md is intended for and almost entirely maintained by coding agents; while it is not written for a human audience per se, it contains a useful architecture overview. Task-oriented runbooks (e.g. provisioning the release signing YubiKey) live in contributing/.