How your data is handled

Students own their projects. There is no administrator role that can read private work, no support path that quietly widens access, and no moderator route into a project. Where this page says something cannot happen, it means there is no database policy that would permit it — not that the interface hides the button.

Your account

Email address and authentication details, held by Supabase Auth. A profile row holds your username, and whatever else you choose to fill in.

Your projects

Everything in a project workspace: notebook entries, documents and their version history, literature sources, tasks, datasets, trials, files, and paperwork records.

Public content

Forum posts and comments, votes, and anything you submit to the resource library or the archive.

Peer review

Review requests, invitations, the reviews themselves, and a record of every access grant with its expiry.

AI requests

For each AI review: which items you selected, a one-way hash and character count of the transmitted text, and the response. New readable transmission text is never stored in the database.

Product analytics

For signed-in users, ResearchForge records an allowlisted event name and generalized route category. It does not record document text, titles, search terms, project identifiers, IP addresses, device fingerprints, or third-party tracking IDs.

Permission changes

An append-only log of every change to who can see what on a project, visible to the project owner on the Sharing tab.

• Your projects: you, plus anyone you have explicitly granted access. New projects are private. Visibility widens only by your action.
• Personal notebook entries: you, and nobody else. No peer-review grant can include them — the column that would allow it is constrained to false.
• Peer reviewers: only the specific documents and sections you grant, and only until the expiry you set. After that they retain access to the review they wrote and nothing else.
• Moderators: public content only — posts, comments, reports, resources, and archive entries. There is no policy anywhere granting a moderator access to a project, its notebook, documents, files, datasets, or peer reviews.
• Your profile: whatever you have switched on in settings. Each field — school, grade, location, email, projects, activity — has its own switch, and the profile page honours every one of them.

Project files and paperwork live in private storage buckets. Downloads use a link that expires within a minute, and the storage rules check the same permissions the rest of the project does — including review expiry, so a link shared onward stops working when the window closes. Avatars, post images, and library assets are public by design.

Only the items you tick are sent, to Anthropic's API, at the moment you press the button. Nothing is sent in the background and nothing is sent on a schedule. Uploaded content is treated as data rather than instructions, and responses are stored in their own table — never merged into your writing. For new requests, readable input stays in process memory only; its hash and itemized selection remain for auditing. If no API key is configured on a deployment, the feature is simply unavailable and nothing is transmitted at all.

Posts, comments, projects, and documents you delete are soft-deleted and stop being served immediately. Deleting your account removes your profile and cascades to everything you own. That is not reversible and no copy is retained for moderators, so export anything you want to keep first.

• Identifiable participant data. Anonymise before it reaches a dataset.
• Anyone else's contact details, including a researcher you are emailing.
• Precise locations of sensitive field sites or protected species.
• Credentials of any kind, including API keys pasted into a document.