Privacy Policy

Effective date: April 30, 2026 • Last reviewed automatically on

1. Who is responsible for your data

For service-level processing (account creation, authentication, billing if and when it begins, security, and operating the platform itself) Fluid Forum is the data controller. During the beta phase the operators of Fluid Forum act as that controller; full corporate identity and registration details will be added here when the operating entity is formed.

For the content that members and administrators upload into a group’s space — ideas, discussion, votes, member rosters, governing documents, archives, and any export — the organisation that runs that group is the controller, and Fluid Forum acts as a processor on its behalf, in line with the Terms of Service and our agreements with that organisation. If you are a member of a group, please refer to that organisation for questions about the content it has chosen to collect.

2. Information we collect

2.1 Information you provide

• Account information. Your email address (used for passwordless magic-link sign-in), and the display name and avatar you choose for your profile.
• Group and membership data. The groups you create, join, or are invited to; your role (member or admin) in each group; invitation messages you send.
• Content. Ideas, descriptions, comments, edit suggestions, attached image references, propositions, voting periods, governing documents, and any beta feedback you choose to submit.
• Votes and delegations. Your Yes / No / Abstain ballot choices, your delegation choices, and any preferences you set for transparency under the Transparency-Threshold Delegation rules described in section 7 below.
• Anonymous posts. When you post anonymously, the substantive content of your post is published under a per-group anonymous identity. Your link to that post is stored separately and protected so that the published post does not reveal who you are. See section 8.
• Notification preferences. Your choices about which email and browser-push notifications you want to receive.
• API tokens. If you choose to use the read-only agent API, we generate a token bound to your account; we store a hashed form of that token, not the token itself.

2.2 Information we collect automatically when you use the Service

• Authentication and session data. Sign-in events, session tokens issued by our authentication provider, and the technical metadata needed to keep you signed in securely.
• Service logs. Operational logs such as request timestamps, IP address, user-agent string, error traces, and rate-limit counters. These are kept for security, abuse prevention, and troubleshooting, and are not used for advertising or behavioural profiling.
• Browser-push subscription data. If you opt in to push notifications, your browser provides a push endpoint URL and public keys, which we store so we can deliver push messages to that browser.

2.3 Information we do not collect

The Service does not embed third-party advertising trackers, analytics pixels, or behavioural-profiling scripts. We do not sell personal data, and we do not use it to build advertising profiles.

3. Why we process your data and our legal bases

Where the GDPR or comparable laws apply, we rely on the following legal bases:

• Performance of a contract (GDPR Art. 6(1)(b)) — to operate the Service, run authentication, deliver notifications you have asked for, process payments if and when paid plans begin, and otherwise provide what you signed up for.
• Legitimate interests (GDPR Art. 6(1)(f)) — to keep the Service secure, prevent abuse, enforce rate limits, investigate fraud, debug failures, and protect the integrity of governance processes (for example, by reviewing content that has been flagged or by acting on AI-moderation outcomes). We balance these interests against your rights and freedoms.
• Consent (GDPR Art. 6(1)(a)) — for browser push notifications, optional AI proofreading on named posts, and any other feature that we explicitly ask you to opt in to. You can withdraw consent at any time, although withdrawal does not affect processing that already happened.
• Legal obligation (GDPR Art. 6(1)(c)) — to retain records we are required to keep, for example to comply with tax, accounting, or law-enforcement requirements when these apply.

4. Sub-processors and other recipients

To run the Service we rely on a small number of carefully chosen sub-processors. They process personal data only on documented instructions from Fluid Forum and under appropriate contractual safeguards, including the EU Standard Contractual Clauses where applicable.

• Supabase — database, authentication, file storage, and serverless edge functions. Data is hosted on AWS infrastructure in the United States (US‑East). Supabase’s standard Data Processing Addendum and Standard Contractual Clauses apply.
• Transactional email provider. An SMTP provider sends magic-link sign-in emails, invitation emails, and notification digests to recipient addresses you have given us.
• xAI — the api.x.ai service is used for AI moderation of anonymous posts, optional AI proofreading of named posts, neutral summaries of decisions, and (when admins opt in) the generation of execution briefs. We send only the content needed for the requested operation and we do not authorise xAI to use your content to train its general models. See section 6.
• Browser push services. When you enable push notifications, your browser’s push provider (for example, Mozilla, Google, or Apple) delivers the encrypted message we send to your device. We never share your account email or content with the push provider; only the encrypted payload and the endpoint your browser issued.
• Dropbox — used by us to store encrypted backups of database snapshots in case of disaster recovery. Backup contents are not made accessible to anyone outside our operations team.
• Arweave / Turbo — used only when a group administrator chooses to anchor a decision packet to the public permaweb. See section 9; once written, those records cannot be edited or removed.
• External execution providers — used only when a group administrator chooses to dispatch an execution brief through the optional execution layer (for example, a service marketplace or AI execution provider). The brief content sent is determined by the administrator at the time of dispatch.

We may also disclose information when we are legally required to do so, when it is necessary to protect the rights, property, or safety of Fluid Forum, our users, or the public, or in connection with a corporate transaction (for example, a merger or acquisition) where we will require any acquirer to honour this Policy or seek your consent.

5. International data transfers

Because our primary infrastructure is hosted in the United States, personal data of users located in the European Economic Area, the United Kingdom, or Switzerland is transferred outside those regions. We rely on the European Commission’s Standard Contractual Clauses (and the UK addendum where it applies) plus supplementary measures — including encryption in transit, encryption at rest provided by our hosting provider, and minimisation of payload data — to give your data an essentially equivalent level of protection. You can request a copy of the safeguards in place by contacting us using section 23.

6. AI processing of content

Several features of the Service rely on a third-party AI provider (currently xAI’s Grok models, accessed via api.x.ai). Specifically:

• Anonymous-post moderation. When you post anonymously, the text of your draft is sent to the AI provider so it can be checked for abuse, doxing, threats, off-purpose content, and tone. Approved content is then published under your group’s anonymous identity. Rejected drafts are not published.
• Optional proofreading on named posts. If you ask for AI suggestions on a named post, the draft is sent for that purpose only. You can ignore the suggestions and publish your original wording.
• Neutral decision summaries. When a voting period closes, we may use the AI provider to produce a neutral summary of the proposal and discussion based on the content already in the group.
• Execution briefs (admin-initiated). When a group admin uses the optional execution layer, the chosen idea’s content is sent to the AI provider to produce a structured brief. Members can see the resulting brief inside the app before any external dispatch.

We send only the content needed for the operation, with prompt-injection sanitisation applied first. We do not authorise the AI provider to use your content to train its general models, and we configure requests so that they are not used for that purpose where the provider exposes such a setting. AI moderation produces an automated outcome that affects whether your anonymous post is published; if you disagree with that outcome, you can edit your post and submit it again, post non-anonymously, or contact a group administrator.

7. Voting and delegation privacy

Casting a vote is by default not anonymous to the system: your ballot is recorded against your account so that delegations work correctly and so that decisions can be audited. Aggregated results (totals, decisions, archive entries) are visible to members of the group; whether individual ballots are visible to other members depends on the group’s configuration and on the Transparency-Threshold Delegation (TTD-C) rules described in the Terms of Service.

Under TTD-C, if a delegate’s combined voting weight exceeds the configured threshold, the delegate must either accept a cap on their voting weight or accept that ballots cast at or above the threshold become visible in the group’s archive. We display this choice clearly before the delegate confirms a vote.

8. Anonymous posting

When you post anonymously, the published post is attributed to your group’s anonymous identity rather than to you. Internally, we keep a protected mapping so we can enforce per-user rate limits on anonymous posting, prevent abuse, and let group administrators take action on a specific anonymous post when our Terms allow it. We do not surface that mapping to other members of your group.

Anonymous posts are subject to AI moderation, as described in section 6. If your draft is rejected by moderation, it is not published; we may retain the rejected draft and the moderation decision for a limited period to evaluate the moderation system and to handle appeals.

9. Optional permanent records (Arweave anchoring)

Group administrators can choose to publish a decision packet to the Arweave permaweb — a public, decentralised storage network — in either of two tiers:

• Public Mandate. The full decision packet (proposal text, outcome, totals, governance metadata) is uploaded in clear text and becomes publicly accessible at a permanent URL.
• Sealed Record. A SHA-256 hash of the decision packet plus an encrypted copy is uploaded; only the hash is meaningful to the public. The plaintext stays inside the group unless the group later chooses to disclose the decryption key.

Arweave records are immutable. Once uploaded, they cannot be edited, redacted, or deleted by Fluid Forum, by the group, or by you. They will remain accessible indefinitely, including after you delete your account or after a group is closed. Please consider this carefully before publishing a decision packet, and avoid including data in proposals that you are unwilling to have anchored if the group later decides to do so. Where the GDPR right to erasure conflicts with this immutability, we cannot guarantee deletion of the on-chain artefact; we will, where possible, remove or anonymise on-chain copies of personal data inside the off-chain Service and document the limitation in our records.

10. Optional execution layer

If a group admin chooses to use the execution layer, the AI-generated brief and any context the admin attaches are sent to one or more external providers (for example, a service marketplace or an AI execution platform) so that those providers can return a quote or proposal. The choice of provider is made by the admin at dispatch time and is shown to the group’s members. Personal data is included in dispatched briefs only to the extent the admin chooses; we recommend that admins minimise personal data in such dispatches.

11. Notifications

Email notifications. If your account is set to receive email notifications, we send you transactional emails (sign-in links, invitations, notification digests, voting reminders, and similar). You can adjust the categories you receive in your profile settings; some service emails (for example, sign-in links and security notices) are required and cannot be turned off while your account is active.

Browser push notifications. If you opt in, we send encrypted push messages to the browsers you have authorised. You can revoke push permission in your browser settings at any time, and we will stop sending pushes to that subscription as soon as we receive that information.

12. Cookies and local storage

The Service uses browser storage strictly to operate. We do not use third-party advertising or analytics cookies. The categories used are:

• Strictly necessary — authentication. Session tokens issued by our authentication provider so that you remain signed in securely.
• Strictly necessary — security. A short-lived CSRF token kept in session storage to protect form submissions.
• Functional — user preference. Your selected group, last visited section, language, theme, and similar interface preferences kept in localStorage to give you a consistent experience across sessions.
• Functional — offline resilience. A small cache of the ideas list and a fallback queue for beta feedback so that the app degrades gracefully when the network is unreliable.

13. Calendar feeds

Each group can expose a calendar feed (iCalendar / ICS format) for its voting periods so that members can subscribe with their calendar of choice (for example, Google Calendar or Apple Calendar). Because most calendar clients cannot send authentication headers, access to the feed is gated by knowledge of an unguessable group identifier in the URL. Treat the URL like a secret; anyone with the URL can read the feed. Group admins can rotate the identifier if it is exposed.

14. Backups, security and incident response

We maintain database backups so that we can recover from accidental loss or corruption. Backups are encrypted in transit and at rest, kept on a rolling schedule, and accessible only to operations personnel. We use technical and organisational measures appropriate to the nature of the data, including encryption in transit (TLS), strict role-based access at the database level, audit logging of administrative actions, and regular reviews of access. No system is perfectly secure, and we do not promise any specific outcome; if we discover a personal-data breach that is likely to result in a risk to your rights and freedoms, we will notify the competent supervisory authority and, where required, affected users in line with applicable law.

15. How long we keep data

We keep personal data for as long as it is needed for the purpose for which it was collected and as long as the related account or group remains active. After that, retention depends on the type of data:

• Account data is kept while your account is active. When you delete your account (see section 17), we delete or anonymise the personal-data fields tied to that account within a reasonable period, subject to the carve-outs below.
• Group content is kept while the group exists and is governed by the group’s admin. When a group is closed, we follow the admin’s instructions and our Terms of Service.
• Voting history and archives are kept for as long as the group keeps them, because they are part of the group’s governance record. Aggregate tallies are retained even after individual accounts are deleted.
• Service logs and security data are kept for a limited period (typically up to 12 months) and then deleted or aggregated.
• Backups are rotated and overwritten on a fixed schedule; data deleted from the live system will eventually be deleted from backups too.
• Immutable on-chain artefacts (Arweave anchors) cannot be deleted; see section 9.
• Records we are required by law to keep (for example, tax records when paid plans begin) are kept for the period the law requires.

16. Your rights

If the GDPR or comparable laws apply to you, you have the right to:

• request access to the personal data we hold about you;
• request rectification of inaccurate or incomplete personal data;
• request erasure of your personal data, subject to legal exceptions and to the immutable-record carve-out in section 9;
• request restriction of processing in certain circumstances;
• request portability of personal data you provided to us in a structured, commonly used, machine-readable format, where processing is based on consent or contract and is carried out by automated means;
• object to processing based on legitimate interests, including profiling, on grounds related to your particular situation;
• withdraw consent at any time where processing is based on consent;
• lodge a complaint with a data-protection supervisory authority — for users in the Netherlands this is the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl); for other EU/EEA users it is the authority in your country of residence or workplace.

We will respond to a verified request within the time limits set by applicable law. We may need to verify your identity before acting on a request, and we may decline or limit a request where the law allows or requires us to do so (for example, where another user’s rights would be affected, or where we must keep a record for legal reasons).

17. Deleting your account

You can delete your own account from your profile settings. When you do, we permanently remove your account and the personal-data fields tied to it from the live system, after a short retention window during which the action can be reversed in cases of accidental deletion. Some constraints apply:

• If you are an administrator of any group, you must transfer admin rights or close the group before deletion can complete; this protects governance continuity for other members.
• Content that is part of the public governance record — aggregate tallies, archived decisions, and any Arweave anchor — is retained as described in sections 9 and 15, even after your account is deleted.
• Backups are overwritten on a rolling schedule, so deleted data may persist briefly in backup storage until the next rotation.

If you cannot complete deletion yourself, contact us using section 23 and we will assist you.

18. Children

The Service is intended for adults aged 18 and over. We do not knowingly collect personal data from anyone under 18. If you believe a child has provided us with personal data, please contact us using section 23 and we will take appropriate action.

19. Automated decision-making

AI moderation produces an automated outcome that affects whether an anonymous post is published. This is an automated decision in the sense of GDPR Art. 22, but it does not produce legal effects on you and is not solely automated in critical contexts — you can edit and resubmit, post non-anonymously, or escalate to a group administrator. We do not use automated decision-making to evaluate creditworthiness, employment, access to essential services, or any similar significant decision.

20. Accessibility of personal data inside groups

Inside a group, members and administrators can see information that is part of normal collaboration: each other’s display name and avatar, the ideas and comments they post non-anonymously, and the propositions they vote on. Administrators have additional visibility appropriate to running the group (for example, member email addresses, invitation status, and moderation logs). Whenever the platform is about to make a piece of personal data more visible than its default — for example by activating delegate-ballot transparency under TTD-C, or by anchoring a decision to Arweave — we surface that fact in the relevant interface before the action takes effect.

21. Changes to this Privacy Policy

We may update this Privacy Policy from time to time to reflect changes to the Service, to applicable law, or to our practices. The “Effective date” at the top of this page indicates the latest version. For material changes we will provide reasonable advance notice, for example by email or by an in-app notice. Continued use of the Service after a change takes effect means you have read the updated Policy.

22. Conflicts and supplementary terms

This Privacy Policy is intended to be read together with our Terms of Service. Where a separate agreement (for example, an organisation-level data-processing agreement) governs the processing of group content, that agreement controls in case of conflict for that processing.

23. Contact

For questions about this Privacy Policy, to exercise the rights in section 16, or to report a privacy concern, please contact us at [email protected]. Please include enough information for us to identify your account or your group, while taking care not to send unnecessary personal data.