We won't promise encryption that would make us blind to your data — the model that runs the conversation has to see it to respond. Instead, honesty: where the data lives, who can see it and how, and what you can do with it yourself.
All data — organizations, conversations, briefs, scores — lives in one isolated database (Postgres, hosted by Supabase). Isolation works at the level of every single table row: the access rule is checked by the database on every query, not just by application code — one organization physically cannot read another's data, even if there's a bug somewhere in the application code.
After any change to the database structure, an automated test re-checks this isolation — the build fails if the test doesn't pass.
Separately from conversations and briefs, we keep technical product events — visited the site, requested a sign-in code, reached a brief, and so on. No content: just the fact that an action happened and roughly when.
Before you sign in, such an event is tagged with a random browser identifier — not tied to your email or name, and it lives in your browser until you clear site data. After you sign in, events are additionally tagged with your user ID — this is so we can honestly count people instead of raw clicks, and separate our own test visits from real ones.
This data only ever surfaces as numbers — the share who reached a brief, how many people came back, and so on. There's no personal activity feed of "what a specific person did" anywhere in the product.
The conversation and the brief are run by Anthropic's commercial API (the Claude model). Under the terms of Anthropic's commercial API, data sent through it isn't used to train their models — that's a separate contractual commitment from the model provider, not a setting on our side that could accidentally get switched off.
If an independent scorer reviews a brief (part of our quality-control system), they see a de-identified version: no organization name, no names, no correspondence — just the conversation itself and the brief's structure. De-identification is done automatically by code, before the brief ever reaches the scorer's screen.
Technically, we — the team running the product — have access to the database: there's no way to fix bugs or keep the service running without it. Our policy is not to read the content of your conversations or briefs without a support request from you.
Such a request is an email to support@extellact.com — there is no other way to make one, and we do nothing "by default" until you write.
Every time a team admin or a scorer opens your idea through the product's screens, it's recorded in a log — you can see it on the idea's page ("Who's opened this idea"). One caveat: the log records that kind of product-level access through the interface — not our team's direct database queries during support or debugging.
You can delete an idea forever from its page — the conversation, briefs, recap, and scores disappear permanently. Overall statistics keep only the aggregated processing cost (what it cost to compute) — not a single word of content.
You can also set a retention period for an idea ahead of time — 90 days, 1 year, or forever (the default is forever): once it expires, the idea is deleted automatically the same way.
Emails — sign-in codes, invitations, reminders — are sent by Resend, a dedicated email delivery service. There's no password: the sign-in code is one-time and stops working after an hour or as soon as it's used.
Questions, data deletion, access to what we store about you — write to support@extellact.com. A human answers.
Published July 19, 2026 · Updated July 27, 2026