How we hold your data
You are about to tell it
the hard thing.
A board is only useful if you bring it the decision you would not put in a group chat. So this page is the mechanics, not the reassurance: what is stored, which table it sits in, who can read it, how long it lives, and the exact database trigger that deletes it when you run a room off the record.
The binding documents are the Privacy Policy, Terms and Security pages. This one explains how they are actually implemented.
- 207 of 207 tables with row-level security
- stored in the EU (eu-west-1)
- no card details ever reach us
What she keeps, with sources
What we hold
What we hold,
and which table it is in.
What you tell her, paste or photograph becomes facts, each tied to where it came from. Nothing is kept as still true until you say it is.
Your questions and every answer
sessionssession_turnsagent_responsesdecision_memosThe full transcript of a board or a consult — the brief, each expert’s turn, the dissent, the memo. This is the product; there is no lighter-weight version of it.
Your World, with sources
session_memoryuser_world_modelsdecision_recordsWhat you tell your Chief of Staff and what you decide, each one tied to its source and date. It is a page you can read and edit, and nothing is kept as still true until you say it is.
The positions you signed
problemsstanding_callsA Call is a position your board took and has to keep standing behind — the position itself, what would flip it, the sharpest argument against it, and which expert owns it. You write and edit every one of those lines before it is kept; nothing is minted without you, and a room run off the record never mints one at all.
What you told an expert they got wrong
turn_feedbackOne row per answer you rated: the verdict, which remembered fact you were pointing at, and up to 500 characters of your own note. It is how a wrong answer gets flagged, so it is stored against your account rather than aggregated away.
Tool connections
integration_connectionsA connection id, the granted scopes, the status and the last-used time. The OAuth tokens themselves are held by our tool provider, not by us — there is no column in our database that could leak your Gmail token, because there is no such column.
What was done in your tools
integration_eventsAn append-only log of every tool call, with payloads scrubbed of personal data before they are written. This is what makes a receipt possible.
Credits and payments
user_creditscredit_transactionspurchase_transactionsWhat you were charged and for what. Card details are never sent to us — the payment processor holds them and we only ever see the outcome.
Account and telemetry
profilesauth_eventsanalytics_eventsllm_provider_audit_logYour email and profile, sign-in events, product usage, and one row per model call for cost accounting and incident forensics.
Isolation
Isolation is a database rule,
not app code.
Application code that forgets a WHERE user_id = … is the single most common way one customer sees another’s data. So the check does not live in application code. Every table in the public schema has row-level security switched on, and the policies on your content all have the same one-line shape.
CREATE POLICY "Users can view own sessions"
ON sessions FOR SELECT
USING (auth.uid() = user_id);The same predicate guards your memories, your decisions, your credits and your tool connections. The privileged functions that search across what is on file are declared SECURITY DEFINER with an explicit search_path, and execute permission is revoked from anon and authenticated — only our server can call them, and only ever with your own user id.
Off the record
Off the record means a delete,
not a flag.
Some decisions should not join the record — the ones about people, or about whether to keep going at all. You can run any room off the record. That guarantee is enforced in two independent layers, and neither of them is application code you have to trust us to have written correctly.
It cannot be read
The search function that feeds every grounded answer filters off-record sessions out of its candidate set before scoring anything. There is no ranking threshold to tune and no prompt to jailbreak — the rows are not in the result.
AND NOT EXISTS (
SELECT 1 FROM sessions s
WHERE s.id = sm.source_session_id
AND s.wm_scope = 'off_record'
)What existed is deleted
Marking a session off the record fires a trigger that deletes its decisions, memos, board artifacts and derived facts from the brain index outright. And the scope locks once a session is underway — the API refuses the change with a 409 — so “off the record” is a decision you make going in, never a scrub applied after the argument went somewhere you did not like.
CREATE OR REPLACE FUNCTION purge_offrecord_brain_rows()
RETURNS trigger LANGUAGE plpgsql SECURITY DEFINER SET search_path TO 'public', 'extensions'
AS $$
BEGIN
IF NEW.wm_scope = 'off_record' AND COALESCE(OLD.wm_scope, '') <> 'off_record' THEN
DELETE FROM session_memory
WHERE source_session_id = NEW.id
AND memory_type IN ('decision', 'memo', 'board_artifact', 'wm_fact');
END IF;
RETURN NEW;
END;
$$;
DROP TRIGGER IF EXISTS trg_purge_offrecord_brain ON sessions;
CREATE TRIGGER trg_purge_offrecord_brain
AFTER UPDATE OF wm_scope ON sessions
FOR EACH ROW WHEN (NEW.wm_scope = 'off_record')
EXECUTE FUNCTION purge_offrecord_brain_rows();Retention
How long
each record lives.
Keeping logs forever is not caution, it is negligence with extra steps. Scheduled jobs purge the 90-day logs on the clock; the API and MCP audit trail is retained for twelve months, and backups roll on a fixed window.
| Record | Kept for | Why |
|---|---|---|
| Sessions, memos, what is on file | While your account exists | They are the thing you paid for; a board that forgets is not a board. |
| Tool-call events | 90 days | Long enough to reconcile billing and investigate an incident. Connect and disconnect events are kept for the life of the account — those are account-security records. |
| Model-call audit log | 90 days | One row per model call. Ninety days covers the longest realistic postmortem window. |
| API and MCP call log | 12 months | Tool name, PII-scrubbed parameters, status, correlation id, caller IP. Kept longer than the other logs because it is the security audit trail for programmatic access. Visible to you under Developers → Usage. |
| Database backups | 90 days | Disaster recovery. A deletion propagates out of backups as they roll. |
Deletion
Getting it
back out.
People mean six different things by “delete it”. Here is what each one actually does — including the two answers that are a “no, and here is why”, stated plainly rather than buried.
A draft you never ran
Hard-deleted immediately, row and all. Nothing was charged and nothing was kept.
A session you did run
Archived, not deleted. A completed board has credits spent and an audit trail attached to it, and we will not quietly rewrite a financial record. Archiving takes it out of every listing.
A fact on file
Yours to edit or remove, one line at a time, from Your World — and a single reset clears the whole dossier.
A tool connection
Revoke it from Settings → Integrations, individually or all at once. Revocation happens at the provider, so the access is gone, not just hidden.
Your entire account
Ask us — there is no self-serve delete button today, and we would rather say so than imply one. Write to us and we run it: every tool connection revoked at the provider first, while we can still prove who is asking, then the auth user deleted, which cascades through every table that references you.
An erasure request
Same channel, wider scrub: every content and telemetry table emptied, the login retired, and only the financial ledger kept, anonymised, because tax law requires it.
Who else
Who else
touches it.
SynthBoard runs on Vercel with a managed PostgreSQL database in the EU. Your prompts and session content go to the frontier model providers that run the seats — they process under their own terms, and the current list is in the privacy policy. Payments go through a merchant of record, so card details never reach our servers. Email is delivered by a transactional provider. The 62 tool connections are brokered by an integration provider that holds the OAuth tokens on your behalf — we store a connection id and the granted scopes, nothing that could be replayed.
One more, because it is the least obvious. When you press Say it instead and talk to your board, the transcription is done by your browser, using the Web Speech API — we run no speech service and we never receive your audio. But most browsers implement that API by streaming the audio to their own cloud: in Chrome and Edge that is Google’s speech service, in Safari it is Apple’s. So for the seconds you are speaking, your browser’s vendor hears it, under their terms rather than ours. Firefox does not implement the API at all, and there the button is replaced by a line saying so. The typed box beside it never leaves this stack — if that matters for what you are about to say, type it.
We do not sell your data, and a session is private until you explicitly share it. A shared link can carry a password and can be revoked at any time.
Never
What is never done
with what you tell her.
Inside the product.
- Run a room without your tap.
- Write to your tools without your confirm.
- Open a new room to explain one that already ran.
- Claim a source she did not read.
- Rate a board’s call above 90.
- Make the hard call for you. The call stays yours.
With your data.
- We do not sell your data.
- A session is private until you explicitly share it.
- Card details never reach our servers.
- We run no speech service and never receive your audio.
- There is no column in our database that could leak your Gmail token.
Questions
Fair questions.
Straight answers.
What people ask before they tell it the hard thing.
Or read the privacy policy · ask us something specific
Can another SynthBoard user see my sessions?
No. Every table in the public schema has row-level security enabled — 207 of 207 tables, 308 policies — and the policies on your content are all the same shape: auth.uid() = user_id. A query authenticated as another user does not return your rows; it returns zero rows.
Where is my data physically stored?
In a managed PostgreSQL database in the eu-west-1 region (Europe, Ireland), with the application served from Vercel’s edge network. Data is encrypted in transit with TLS 1.3 and at rest with AES-256.
What does “off the record” actually do?
Two things, in two layers. The search function that feeds your board excludes any memory whose source session is off the record, so it cannot be read even if it exists. And a database trigger deletes those memory rows outright the moment a session is marked off the record.
Do you sell my data or share my sessions?
No. Sessions are private until you explicitly share one, and a shared link can be password-protected and revoked. Your prompts do go to the model providers that run the seats, which process them under their own terms — the current list is in the privacy policy.
If I talk to my board instead of typing, who hears it?
Your browser does the transcription, not us — we run no speech service and never receive the audio. The catch worth knowing: most browsers implement that API in their own cloud, so Chrome and Edge stream the audio to Google’s speech service and Safari to Apple’s, under their terms. Firefox has no speech recognition at all, and there we show a line saying so instead of a button that cannot work. Only the text you keep after editing it is ever stored, and the typed box beside the mic never leaves our stack.
How do I delete everything?
Write to us through the contact form and ask. There is no self-serve delete button in the product today. We revoke every connected tool at the provider first, then delete the auth user, which cascades through every table that references you. It is not reversible.
