Privacy Policy

• Account data: email + display name + avatar from your OAuth provider (GitHub / Google).
• Waitlist signups: your email, the plan you asked about, and the exact wording on the screen when you signed up, with the date — kept because Canada's anti-spam law (CASL) requires us to prove consent, not just assert it.
• Diagrams: the source code you write. Every workstation is behind sign-in, and while you are signed in we automatically attempt to sync your whole workspace — the source of each diagram, every studio's documents, and your Vault snapshots — to our database after edits. There is no opt-out today. Your browser also attempts to save a local copy. Until a cloud save succeeds, this device may hold the only copy. An expired session, a network problem or a rejected save can interrupt backup. Check the save and cloud-sync status and keep an export of important work. Separately, a share link carries the diagram's full source inside the link itself, so our servers read it whenever that link is opened.
• Study: your decks and cards, your review history (one row per card or concept you review, with the rating and how long you took), your course progress and your Study preferences. While you are signed in these sync to our database so they follow you between devices. Pictures on cards are not synced; they stay on the device where you added them.
• Usage telemetry: anonymous, first-party product events keyed to a random per-browser id. Section 4 lists every field.
• Feedback: the message you send through the in-product feedback door — with your user id and email attached if you were signed in. Section 5.
• Customer support: support tickets contain your account email, topic, subject, message, source, status and delivery timestamps. They are visible to you and authorised support staff, included in your account export and deleted with your account.
• Email delivery records: when delivery tracking is enabled, we keep send and provider-event identifiers, timestamps, delivery status, and hashes used to match a send with its delivery report. These private operational records contain no message body or subject. Hashes can still be linked to a recipient; we do not treat them as anonymous analytics or use them for marketing.
• Error reports: details of crashes in your browser or on our servers, so we can fix them. Section 6.
• Security log: an append-only record of account and billing events — API-key creation and revocation, saving or deleting a stored AI key, plan changes and AI-point top-ups, joining the waitlist, and account deletion. What a row carries depends on where it was written: an event that came from a request you made records your IP address and your browser's user-agent string, while an event that came from our billing provider's webhook records your user id and no IP. Sign-in and sign-out produce no row here — they happen at our authentication provider, which keeps its own log. This is the one place we keep an IP. It exists to investigate account takeover and billing disputes, and it is never used for analytics or advertising.
• Security monitoring log: a record of security-relevant moments, used to detect and block attacks on the platform — failed sign-ins and sign-in codes, second-factor failures, sign-ups, refused cross-site requests, rate-limit refusals, requests for paths only attackers ask for, blocked attempts to make our servers fetch internal addresses, API-key and billing events, and blocks placed or lifted. It does not store your IP address as written: it keeps a keyed hash of it (for IPv6, of your network's /64) and a masked form with the last part removed (for example 203.0.113.x), your browser's user-agent string cut to 256 characters, the page or API path, and your user id when you are signed in. For a failed sign-in it keeps a hash of the email address typed, never the password. Only administrators can read it; entries are deleted after 30 days. Alerts and blocks derived from it are kept as the record of an enforcement decision.
• Billing: if you subscribe, Stripe holds your card details — we only store the subscription status and tier.

• We don't train AI models on your diagrams.
• We don't sell or rent your data.
• We don't use third-party analytics, ad trackers, or cross-site tracking of any kind.
• We don't read your cloud-synced diagrams except to render them back to you.
• We never store your AI provider API key in plain text, and we never log it.

When you use an AI feature, your prompt and the relevant diagram context are sent to the AI provider handling the request. On the hosted allowance that is Anthropic or OpenAI; if you brought your own key, it is the provider you chose — Anthropic, OpenAI, Google, DeepSeek, Alibaba (Qwen), Zhipu (GLM), Moonshot (Kimi) or Mistral. The provider's own privacy policy applies to that leg of the call. We don't retain the prompt or the completion after returning it to you, with one exception: each agent run keeps a short record — the first 280 characters of what you typed, the tools it called, how it ended and the points it cost — so your account page can show you what ran. It never holds the model's reasoning, the diagram or your key.

If you bring your own key (BYOK) there are two modes, and they handle your key differently. Both of them route the key through our server — the provider call is made server-side, so a “browser-only” BYOK is not something we can honestly claim:

• Kept in your browser (the default). Your key is stored in your browser's local storage and attached to each AI request as an X-User-Api-Key header. Our server holds it in memory only for the lifetime of that one request, uses it to call the provider you nominated, and never writes it to a database or a log. Provider errors are the one place a key could have escaped that — some providers quote the key back in a rejection message, and those messages go into our crash reports — so every crash report is scrubbed for credential-shaped text before it is written anywhere, including our own server log.
• Saved to your account (opt-in). If you turn on “save key to my account”, the key is encrypted on our server with AES-256-GCM and only the ciphertext, initialisation vector and authentication tag are stored in our database. The encryption key lives in the deployment's environment and never touches the database, so a copy of the database alone does not reveal your key. The row is readable only by the server, gated on your signed-in session; the database's own access rules deny every client role outright. We also store the first 8 characters of the key in clear text so the settings screen can show you which key is saved (sk-ant-x…). We decrypt it in memory, per request, only to call your provider. You can delete it at any time from Settings, which removes the row.

If you don't bring a key, requests use the platform's own provider key and are subject to the quotas described in the Terms.

Telemetry is first-party and anonymous. There is no third-party analytics SDK anywhere in the product. A telemetry row contains only these fields:

• A random browser id — a UUID generated in your browser on first use and kept in local storage. It is not derived from your account, your email, your IP or your device; clearing site data gives you a new one.
• An event name from a fixed, short list (opening a workstation, a successful render, an export, a handoff, a vault save, a feedback submission, and similar).
• The workstation id the event happened in (for example studio) — an identifier, never a URL.
• A small properties bag capped at 900 characters — only approved categories and numbers, such as which engine rendered or which export format was chosen. Search queries, document titles and other free text are discarded before collection. Signup, save and confirmed paid-checkout milestones contain no account or payment identifiers. These describe a browser journey, never an account.
• A timestamp.

We do not store your IP address, your user-agent string, a referrer, a full URL or any query string with telemetry, and telemetry rows are never linked to your account. Diagram source, notes and file contents are never sent. Earlier versions allowed zero-result command searches to include truncated search text, and feedback or error records could carry the browser id. Those historical records follow the retention rules below; we do not use them to identify acquisition cohorts. The current browser analytics identity starts fresh without copying or mapping the old identity, and we remove retired browser identifiers when storage permits. Current analytics requests omit account cookies and referrers. The analytics endpoint discards batches from retired clients and requests carrying cookies or a referrer before reading their event payload. An old open tab may still attempt to send until you refresh it; discarded batches do not become telemetry rows.

Retention: a nightly job deletes telemetry rows more than 90 days old. It removes up to 50,000 rows per table per night, so after a backlog some rows can survive a few days past the 90th.

Turning it off: we honour your browser's Do-Not-Track and Global Privacy Control signals. You can switch telemetry off below, or permanently by setting glyph:telemetry:disabled to 1 in local storage. Turning it off discards events still waiting to be sent. We do not collect referrers, UTM parameters or other acquisition tags, or join anonymous usage to billing accounts.

The in-product feedback door stores your message, the page path you sent it from. New feedback does not include your telemetry browser id and is not joined to your anonymous usage journey.

If you are signed in when you submit, we also store your user id and your email address — so that we can reply to you. That means signed-in feedback is identifiable, not anonymous. If you want to send something anonymously, sign out first: submissions from signed-out visitors carry no user id and no email.

Customer support and optional AI help

Submitting a support request stores the ticket in our database and sends a receipt and a notice through our email provider. Authorised support staff can review and respond using the support inbox. Ticket records remain until account deletion; copies of emails in our email provider and support mailbox follow those services' retention policies. Please do not include passwords, API keys or payment-card details.

When delivery tracking is enabled, we retain delivery events only after matching them to a verified Flowss send receipt. Unmatched reports are discarded without creating delivery records or changing email preferences. Authorised staff can review Flowss sends with an uncertain outcome. Our separate delivery records expire after 14 days and are deleted by an hourly cleanup job; this does not set our email provider's or mailbox's own retention period.

The help assistant initially matches your question to reviewed Flowss guidance on your device. When optional AI assistance is available, signed-in users must separately agree before sending one general question, up to 500 characters, to Anthropic to choose a help topic. We do not send account identifiers, email addresses, projects, tickets, conversation history or saved API keys. This feature does not save questions or place them in product telemetry. The provider processes that question under its applicable service terms and privacy policy. The assistant has no tools to change your account or data.

Optional support voice input requires your consent on each visit and uses only supported, on-device English speech recognition with an already installed language pack. It has no remote speech fallback. A microphone session stops after 30 seconds or when you stop, withdraw consent or leave the page. Audio is not recorded or uploaded. The transcript remains editable on your device and reaches Anthropic only if you also consent to AI assistance and submit it. Spoken replies use an available local English voice. Questions and transcripts are kept only in the current page's memory unless you submit a support ticket.

When something crashes — in your browser or on our servers — we record the failure so we can fix it. A crash report contains the error message, the stack trace, whether it happened on the client or the server, the page path (never the full URL, so share tokens in query strings are not captured), the build identifier, your browser's user-agent string, andyour user id if you were signed in. New error reports do not carry your telemetry browser id and are not joined to anonymous usage analytics.

Stack traces and error messages can incidentally contain identifiers from whatever you were doing when the crash happened. We use these reports for one purpose only: finding and fixing bugs. They are never used for analytics, profiling, marketing or any automated decision about you. They are readable only by the server, are pruned on the same 90-day schedule as telemetry, and if the deployment is configured with an external error-tracking endpoint (Sentry), a copy of the report is forwarded there as well.

Read-aloud is currently switched off. This refers to Study's speech-model feature: it does not download a voice model or play speech today, and Hugging Face receives no request from it. The optional support voice described above uses separate browser-local capabilities. The Study engine remains unmounted; the following paragraphs describe it if it returns.

When it is on, the platform voice runs a speech model entirely inside your browser. The text being read never leaves your device and never reaches our servers — there is no speech API call to log.

It does need the model itself. The first time you use it, your browser downloads roughly 80 MB of model files directly from the Hugging Face CDN (huggingface.co and its content hosts). That is a request from your browser to a third party we do not control, so Hugging Face will see your IP address and the usual request metadata, governed by their privacy policy rather than this one. The files are then cached locally, so it happens once.

It is not the only one, and the rest carry more than a file name — what you wrote, or what you typed. Each is your browser talking to that party directly, so each sees your IP address and the usual request metadata on top of what is listed here, under their privacy policy rather than ours:

• RCSB PDB (files.rcsb.org) — the four-character structure id a molecular document asks for with fetch: 1CRN. The picture is still drawn in your browser; only the identifier leaves it. A molecule whose coordinates are written into the document makes no request at all.
• Whatever host your own document names — a Vega or Plotly spec can point at an external data URL, and your browser goes and gets it. One of the chart templates we ship points at cdn.jsdelivr.net for its sample data. This is your document asking for something rather than us sending it, but the request still carries what it asked for.

Three leave the platform without leaving your browser first. Online icon searches in the Studio, Weave and Science icon pickers are relayed by our own server to Iconify (api.iconify.design, or its mirrors api.simplesvg.com and api.unisvg.com when it is unavailable): the words you type into an icon search box, plus the id of each online icon you preview or place. Iconify sees our server's address, not yours. The words travel in the request address, so they can appear in our hosting provider's short-lived request logs; we keep them nowhere else, and the answers are cached as the public data they are. The icon sets bundled with the app are searched in your browser and send nothing. No diagram content either way.

PlantUML and Kroki diagrams are relayed by our own server to a render service — the public plantuml.com and kroki.io unless whoever runs this deployment has pointed them at their own. Section 11 says the same thing about exporting a PlantUML diagram.

For Kroki that means two things worth being plain about. Your diagram source for those 11 engines — Bytefield, Structurizr DSL, SVGBob (ASCII), ERD, Excalidraw, WireViz, Ditaa (ASCII), Symbolator (HDL), Network (nwdiag), Packet diagrams (packetdiag), Pikchr — passes through our servers on its way to be drawn. We do not store it and we do not log it, but we handle it, and until recently we did not: the browser used to post it to Kroki itself. In exchange, Kroki no longer sees your IP address, only ours. And a deployment that runs both this platform and its own Kroki inside one network now keeps that source inside it — which the browser-side version could not deliver, because the policy permitting the connection and the bundle making it were decided at different times. (A hosted deployment pointed at an internal instance is the case that does not work, and did not work before either.) No other engine sends Kroki anything.

That is the list for drawing and assets, not the whole list of parties involved in the service: cloud sync is sections 1 and 9, AI providers section 3, payments section 1. The full account of who receives what — including the ones that never touch your browser — is in the engineering document section 9 offers to send you.

Cloud-synced diagrams live in a managed Postgres database with row-level security — only you can read your rows. API keys you create (for headless rendering) are stored hashed; we can never recover them once issued. Saved AI provider keys are encrypted as described in section 3.

Cloud sync is not a backup service. We do not currently offer point-in-time recovery or a restore guarantee, so please keep your own copies of anything you cannot afford to lose — every diagram exports to SVG, PNG, PDF, TikZ and JSON source, and the JSON round-trips back into the workspace.

The full engineering detail — encryption, the content security policy, the embed sandbox, rate limits and our subprocessors — is documented internally rather than published. Ask us for it at hello@flowss.ai and we will answer in writing. To report a vulnerability, the contact and our safe-harbour commitments are at /.well-known/security.txt.

• Telemetry and error reports: 90 days, swept nightly. A copy of each error report also reaches our hosting provider's server logs, and our error-monitoring service when one is configured; those age out on their own schedules rather than ours.
• Agent run records: 90 days, swept nightly with the error reports, and deleted with your account.
• Security monitoring log: 30 days, swept nightly. Deleting your account removes the link between these entries and you; the hashed and masked entries themselves age out on the same schedule.
• Account data and cloud-synced diagrams: for as long as your account exists.
• Support tickets: for as long as your account exists. Account deletion removes the ticket records; copies already delivered to mailboxes and our email provider follow their own retention schedules.
• Operational email delivery records, when enabled: 14 days from creation, with hourly deletion of expired records. A copy can remain in database backups until those backups expire.
• Database backups: the database is backed up daily, and each backup is kept for our database provider's backup retention period and then discarded. Anything deleted from the live database — a diagram, or a whole account — is still in the backups taken before it was deleted until those age out.
• Feedback messages: kept until we've acted on them. Deleting your account does not erase the message — it is usually a bug report we acted on — but it does blank every identifier attached to it: the email address, the account link, and the anonymous browser id. What survives is a sentence about the product with nobody's name on it. If you want the text gone as well, ask us and we'll delete it.
• Security log entries: kept while they have forensic value for account-security and billing questions. Deleting your account keeps them and removes your account link, and it also strips out the payment-processor ids some of them carried — a customer or subscription id on an unlinked row is one lookup away from your name, so it goes before the link does.

• Export every diagram you've created. Each one exports from the workstation it lives in — SVG, PNG, PDF, TikZ and JSON source, and the JSON round-trips back in. Two things that sentence should not be read to promise. It needs an account: every workstation is behind sign-in, so there is no anonymous export. And only the source buttons — Copy source, Download source and the clipboard copies — stay entirely in your browser. SVG, PNG and PDF go to our export route first, which sets the download headers and hands the same bytes straight back without storing them; your browser assembles the file locally only if that request fails. A PlantUML diagram is rendered by plantuml.com. TikZ is not a local conversion at all — your diagram source goes to our server and on to an AI provider. Each export also records one telemetry event carrying the format and the engine, and nothing of the diagram itself.
• Download everything we hold about you, yourself, from your account page. The button builds one JSON file with the rows in our account-data inventory attributed to your account or your email address, table by table, each with a sentence saying what it is — including the tables holding nothing, because “we hold nothing here” is part of the answer, and including the contents of the research atlases you own, since deleting one takes its sources, claims and synthesis runs with it and this file is the only copy. Nothing is reviewed or approved by a person first.Three kinds of thing are held back, and the file says so at the table where it happens. Live secrets: an API key appears as its prefix and never its hash, a saved AI provider key as its provider and prefix and never its ciphertext, an unaccepted invitation without its join token. Another account's identifier: an invitation somebody sent to you records the internal user id of the person who sent it, and that identifies them, not you. Rows that belong to a project rather than to a person: the diagram data of a project you can open but do not own stays with the project, as does the sync history of a repository binding. What the file holds there is your side of it — your membership and role, your comments, your entries in its activity feed.Private email delivery records are listed separately in the export's manual privacy review notice. A record may refer to multiple recipients or security-related fingerprints, so matching an email hash alone cannot establish which fields may be disclosed. Contact hello@flowss.ai for a verified, individually redacted copy or an erasure review. These records follow the 14-day retention above and are not automatically removed with account data.
• Request account deletion through the support form or hello@flowss.ai. Self-service account deletion is temporarily unavailable while we improve protection for shared work. Contact support for help with an earlier incomplete request too. A request does not delete your account or cancel your subscription. You can still export your data from Account and use Manage billing for subscription controls.Intended erasure scope, currently paused. The inventory below describes the intended erasure and retention behavior; it is not running while self-service deletion is unavailable. Support will review your request and confirm next steps. Completed erasure is irreversible: we do not restore deleted accounts. Your rows do remain in the database's daily backups until those age out (section 10); they exist to recover the service from a failure, not to bring back one account. The intended process settles billing before erasing data: every live subscription on your customer record at our payment processor is cancelled — not just the one this database happens to have a pointer to — and if any of them cannot be cancelled the deletion stops there rather than leaving you billed for an account that no longer exists. The erasure inventory covers:
  • Your profile and your ability to sign in — name, email address, avatar, preferences
  • Your cloud workspace and every diagram in it
  • Projects, teams and research atlases nobody else belongs to, contents included
  • Your research-atlas work even where the atlas itself survives you: your canonical entities, every concept→entity link pointing at one of them, and your include/exclude screening decisions. A concept link lives in whichever atlas the concept was in, so some of what this removes disappears out of other people's research; a co-author of an atlas you hand on keeps the sources and loses the record of who screened them
  • Your API keys and your saved AI provider key — integrations using either stop working
  • Your plan, AI points and point purchases; a live subscription is cancelled before anything is erased
  • Your comments, sketch components, coursework submissions, usage counters, agent run history, crash reports, and the log of emails we sent you
  and deliberately keeps the following, which is the part a policy is tempted not to spell out:
  • Your unsubscribe and spam-complaint records, kept indefinitely against the address alone. Erasing them would not undo the instruction, it would make us forget you gave it — and mail you again the next time the address appears anywhere
  • Security-log entries, unlinked from your account but keeping their IP and user agent. An audit trail the audited party can erase is not an audit trail, and these rows are the evidence in the two disputes people raise after leaving: 'someone else used my account' and 'I was charged after I cancelled'. The payment-processor ids some of them carry — customer, subscription, checkout session — are stripped out first, because a row that still points at your Stripe customer is one lookup away from your name and your card
  • Feedback you sent us. The message stays; your email address, account link and device id are wiped off it
  • Things other people are attached to: invitations you sent, the coursework you set on a class, a recommended flowss Academy path you set for a team, the links between a shared project's diagrams and its repository, and replies other people wrote under your comments. Your authorship link is removed; the thing itself carries on for them — an assignment in particular, because every student's submission hangs off it
  • A research atlas you share with somebody else is handed on, not deleted and not left ownerless. Unless one of the remaining members already holds the owner role, a successor is promoted to owner first — a sitting editor, or else whoever has been on it longest — because access and administration come from the membership row and not from the owner field, and an atlas with no owner-role member is one nobody can rename, share or delete ever again. Its sources, claims and synthesis runs stay exactly as they are. If every other member has left by the time you confirm, there is nobody to hand it to and it is deleted with the rest
  • Risk-of-bias judgements you recorded against studies in a research atlas somebody else is still using, with your authorship link removed. The judgement itself stays because it is what GRADE's study-limitations domain reads: withdrawing it when the assessor leaves would quietly downgrade every finding in a live review, and the people still working on it would have no way of seeing why the rating moved. Your note on it goes with your name
  • The activity feed of every project you worked on, with your entries kept but emptied. Which project, what kind of event and when survive, so the people still using that project do not find holes in their history; your name, your account link and the preview text each entry carries — the opening of a comment, the address on an 'added a member' line — are wiped off it
  • Security monitoring records, unlinked from your account: entries in the security monitoring log (a hashed and masked network address, never the address itself, deleted after 30 days anyway), security alerts raised about activity on the account, and any account or address blocks placed on it. A security record the account holder can erase is one whoever took the account over can erase; with the link removed none of it names you. If you were an administrator, the platform's security settings you last changed simply forget that it was you
  • Invoices and charges held by our payment processor. Deletion cancels the subscription but leaves the customer record, because that is the copy of the financial history tax and accounting law requires us to be able to produce
  • Product telemetry, which is keyed to a random per-browser id and never carried your account or address; it ages out on the 90-day schedule either way
  One thing more survives, and it is not in that list because it is not your data: the deletion writes a record of itself, and keeps it indefinitely, so that “was this account deleted, and when?” can still be answered once there is no account left to ask. It holds the date and a count of what was removed, and it identifies you only by a one-way fingerprint of your account id — not your name, not your address, not the id itself. The same fingerprint appears on the security-log entry that tells whoever inherits a research atlas how they came to own it. It names nobody on its own; somebody who already holds your account id can check it against the fingerprint and confirm a match.A project or team that has other members stops the deletion before anything changes — removing you would take their work with it, so transfer ownership or remove the other members first. A class you teach that still has students on it also stops it, for a different reason and with a different remedy: the class would survive your account, but it would be left with nobody able to post assignments, read submissions or manage the roster, and there is no way to hand a class over from inside the product — so that one needs a person at our end rather than something you can do yourself. A class nobody else has joined is not shared work, and is deleted along with the assignments you set on it. A shared research atlas does not have to stop anything: it is handed to one of its remaining members — someone holds the owner role on it afterwards, promoted if nobody else already had it — and it keeps its sources and its history. What still leaves with you is your own part of it — your screening decisions, and the concept links pointing at your entities, in that atlas and in every other one they appear in.A shared research atlas is handed on, which is more than being unlinked from it. Administering one — renaming it, inviting or removing people, deleting it — is decided by your role in its member list and not by whose name sits in its owner field. So unless somebody still on it already holds the owner role, one of them is promoted to it before your name comes off: a sitting editor if there is one, otherwise the longest-standing member. An atlas that turns out to have nobody left to promote is deleted rather than left alive with nobody able to touch it.An earlier deletion request may have left a part-finished account. Data already erased stays erased. Contact support to review an incomplete request; self-service retries are unavailable while we improve the shared-work protections.

Exports remain self-service. Account deletion and the following privacy requests go through support.

Send any of these to hello@flowss.ai:

• Correct anything we hold, or request erasure of something the account-erasure inventory keeps — the text of a feedback message, for instance.
• Object to, or ask us to stop, any of the collection described above. Telemetry you can switch off yourself (section 4).

We answer within 30 days and confirm when it's done. Tell us if your request involves shared work or an earlier incomplete deletion so we can review its scope with you. A support request is not confirmation that erasure has happened; we will confirm the outcome after review.

Voranox Inc. is a Canadian company, so these requests are handled under PIPEDA. If you are not satisfied with how we answer one, you can complain to the Office of the Privacy Commissioner of Canada. Being outside Canada does not remove these rights: where the GDPR or a comparable law gives you more, we apply the stronger one.

flowss is operated by Voranox Inc., which is the organisation accountable for the personal information described in this policy — the data controller, in GDPR terms. Everywhere this policy says “we”, it means Voranox Inc.

Privacy questions, data requests, or complaints: hello@flowss.ai. It is a monitored mailbox read by the people who build flowss, not a ticket queue — and it is the same address on the contact page, which says what to expect after you send.