Zero-knowledge, by design
The most important fact about The Architect is one most software companies would consider a bug: our users' journals are stored beyond our reach. Not "we choose not to look." Not "only certain employees can." There is nothing readable to look at.
Every journal entry is encrypted in the browser, on the user's device, with AES-256-GCM, before a single byte travels to our servers. The key that encrypts it is generated on that device and stays there. What we store of your journal — what a breach would leak of it, what a subpoena of our database would produce of it, what a rogue employee would find — is ciphertext. (Ordinary account records — an email address, a billing status — exist here as at any company. Your words do not sit beside them.)
A promise can be broken by a new hire, a subpoena, or a bad quarter. Architecture can't.
Why go this far
A journal is the most sensitive database a person owns. People write to The Architect about their marriages, their fears, their money, the things they have never said out loud. Software that hears that has exactly one acceptable privacy posture: the company on the other end should hold nothing it could ever read back.
The industry's standard answer — a privacy policy, an access-control matrix, an annual audit — is a stack of promises. Promises are only as durable as the people and incentives behind them, and companies outlive both. We wanted a guarantee that survives us on our worst day. Encryption at the edge is that guarantee.
What it costs
Honesty requires saying what this architecture gives up, because the costs are real:
- We cannot "just restore" a lost key. If a user loses their device and never set up recovery, their history is gone. We built a user-initiated recovery key flow precisely because there is no back door for support to use — on purpose.
- No server-side features on journal text. Search, analysis, and the mentor's memory all have to be engineered around the fact that the server never stores plaintext. It would be far easier to build these the ordinary way. We don't.
- We fly partially blind. Our analytics can see that entries are written — shapes and counts, never contents. Every product decision is made without reading a single user's words. It is a harder way to build. It is also the point.
Where the boundary sits
One thing we will always say plainly: a mentor still has to read the entry you hand it. When you ask for a reply, that entry is processed in the moment to generate the mentor's response — and never logged or kept in plaintext. At rest, there is only ciphertext. "Zero-knowledge" is a storage guarantee, not a magic trick, and we would rather draw that line precisely than let it blur into marketing.
The test we apply
When we evaluate any new feature, the question is not "will users allow this?" It is: if every email we ever wrote became public, would this feature still look honest? Zero-knowledge encryption is what that question looks like, compiled into a system.
The Architect is live at architectapp.ai. The privacy claims above are not marketing copy — they are how the system is built, and we are glad to answer technical questions about them: hello@bekirlabs.com.