Can another SynthBoard user see my sessions?

No. Every table in the public schema has row-level security enabled — 194 of 194 tables, 359 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.

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.

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 take a table off the record.

194 of 194 tables with row-level securitystored in the EU (eu-west-1)no card details ever reach us

The binding documents are the Privacy Policy, Terms and Security pages. This one explains how they are actually implemented.

What we hold, and which table it is in.

Your questions and every answersessions, session_turns, agent_responses, decision_memos: The 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 modelsession_memory, user_world_models, decision_records: The facts your board carries between sessions, each one tied back to the session that produced it. It is a page you can read and edit — a value you pin outranks anything the board infers later.
Tool connectionsintegration_connections: A 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 toolsintegration_events: An append-only log of every tool call, with payloads scrubbed of personal data before they are written. This is what makes an undo and a receipt possible.
Credits and paymentsuser_credits, credit_transactions, purchase_transactions: What 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 telemetryprofiles, auth_events, analytics_events, llm_provider_audit_log: Your email and profile, sign-in events, product usage, and one row per model call for cost accounting and incident forensics.

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.

194 of 194 tables · 359 policies · counted against production on 22 July 2026

The policy on your sessions

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 your world model 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 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 table 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.

1 · 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.

Inside search_world_model()

AND NOT EXISTS (
  SELECT 1 FROM sessions s
   WHERE s.id = sm.source_session_id
     AND s.wm_scope = 'off_record'
)

2 · 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.

Verbatim — supabase/migrations/20260719T04_world_model_brain_index_foundation.sql

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();

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, world-model facts	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.

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.

01A draft you never ranHard-deleted immediately, row and all. Nothing was charged and nothing was learned.
02A session you did runArchived, 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.
03A fact in your world modelYours to edit or remove, one line at a time, from the World Model page — and a single reset clears the whole dossier.
04A tool connectionRevoke it from Settings → Integrations, individually or all at once. Revocation happens at the provider, so the access is gone, not just hidden.
05Your entire accountAsk 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.
06An erasure requestSame 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 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.

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.

Straight answers.

Can another SynthBoard user see my sessions?: No. Every table in the public schema has row-level security enabled — 194 of 194 tables, 359 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.
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.

Convene your board Ask us something specific