What we can and cannot see, and why the architecture, not our word, is the answer.

Before you hand over twenty years of email, the reasonable question is what Mandaire can actually do with it. The honest answer is less than you might assume.

Architectural constraint, not a policy position.

Your information is encrypted with a key derived from your password before it is written to disk. We do not have the key. This is an architectural constraint, not a policy position. The analogy that works is Signal. Signal does not have the keys to your messages either. That is not a statement about Signal's trustworthiness. It is a statement about what Signal's servers are structurally capable of. A government request, a hosting breach, or a Mandaire acquisition all produce the same result for the requester: encrypted blobs they cannot read.

Two questions come up consistently. The first is whether Mandaire reads your email to train a model. It does not. Your information is ingested to build your personal picture and used for nothing else. The LLM that reasons over your context is the one you bring: Claude Max, ChatGPT Plus, Gemini. Mandaire is the memory layer; the inference is yours. Neither sees more than the specific context needed for the specific question.

The second is what happens if Mandaire shuts down. You get your data back. Full export of your email index, decision ledger, taste memory, and relationship graph in portable formats. The encryption module is open-source under AGPL, which means any competent engineer can read your archive without Mandaire's involvement. No lock-in is an architectural commitment rather than a preference, because one of the bets the system is built around is that it should be useful without being load-bearing.

The honest list of what works today, what is next, and what requires your reach.

A page that publishes a failure admission referencing "Signal is not yet a connected source" should also name the full connected-source list so you can decide whether your stack is supported before you onboard. As of this writing:

Source Status Notes
Gmail / Google WorkspaceLIVE20-year backfill supported; live sync via API
iCloud MailLIVEIMAP; live sync
Google Calendar / iCloud CalendarLIVECalDAV; live sync
iMessageLIVERequires a Mac mini on your network (or ours); messages stay local
WhatsAppLIVEVia Matrix bridge; phone QR-scan to connect
iCloud PhotosLIVEFace / GPS / scene indexed; binary content not stored remotely
Contacts (Google + iCloud)LIVECardDAV / People API
ChatGPT / Claude / Gemini conversation historyLIVEDrop the export ZIP; backfill in minutes. Live ChatGPT capture via Chrome extension
TripItLIVEEmail-forwarding ingest + Chrome-extension scrape for past trips
Notes (Apple / Google Keep)LIVERead-only
LinkedIn (people-graph, connections, posts you authored)LIVEVia Chrome extension; rate-limited to respect LinkedIn TOS
SignalNEXTQ3 2026; meanwhile decay flags carry a "Signal-blind" caveat for relationships you message there
Telegram / DiscordNEXTQ3 2026 via Matrix bridges (same pattern as WhatsApp)
Microsoft 365 (Outlook / Teams)NEXTQ4 2026; gated on multi-tenant work-account isolation review
Slack (workspaces you own)NEXTQ4 2026
Notion / Obsidian / JoplinBACKLOGFrequently asked; not yet scheduled. Workaround: export to markdown and drop into the chat-history uploader
Facebook / Instagram messagesBACKLOGVia Matrix bridge (mautrix-meta); waiting for Meta connector maturity

If your stack is mostly LIVE, you can onboard meaningfully in the first week. If your most-load-bearing channel is in NEXT or BACKLOG, tell us when you request access and we will be honest about whether the value lands for you in this beta window or whether you should wait for the relevant connector.

If your stack is supported, the next step is one email.