Access control, audit trail
and data isolation, in detail.

Only your institution. Every project and audit record carries its scope — the institution, or the individual who created it — and row-level security filters every read and export to that scope. Inside a workspace the roles differ: owners and editors can change the workspace’s projects, a viewer’s write is refused by the database itself, and each member also sees their own activity. Platform administrators are the one stated exception: they can read across institutions for support and compliance work, and doing so is itself recorded.

Not silently. Administrative access to another institution’s project requires a declared reason, is recorded on the server before any content is returned, and appears in your audit trail as a vendor-access event you can read at any time.

Measurement matrices and working data stay in this browser’s device storage; the cloud record holds session settings, results tables, annotations and report text, and never measurement rows. Every store the app keeps on the device — workflow data and metadata, enrichment caches, saved project payloads — is cleared when you sign out or a different account signs in on this browser. Workspace erasure removes the workspace’s project records and clears the device that ran the erasure; other members’ browsers keep their own local copies until they sign out or switch account. Audit records are stored in the app database.

Two kinds of paths. Reference lookups send the identifiers you query — gene symbols, metabolite, lipid and taxon names, pathway IDs — from our server to the named public databases. Beyond those lookups, a named set of our own server-side paths receives data: single-cell archive parsing, Olink export parsing, proteomics differential fitting, transcriptomics permutation and lncRNA work, and the metagenomics pipelines. AI-drafted report sections are generated by the model provider from your results tables. No measurement matrix is sent as part of a lookup, and the table below states exactly what each path receives.

Tenant boundary on every row

Projects carry the institution identifier. Row-level security filters reads, updates and deletes to your institution, and a project can only be created inside its creator’s own institution.

Membership stays authoritative on the server

The institution record owns the member list and each member’s role. The copy on the user record is reconciled server-side on every session; a browser that writes it directly is detected, recorded as a denied access event and reverted. The same record carries the single scope a member may write in, and row-level security compares each project against it: which is why a viewer cannot save into the workspace even through the API.

Shared caches are scoped too

Annotation caches hold the identifiers people query. They are readable only within the institution that produced them (or by the individual who did), or by administrators for reference data: never across institutions.

Tamper-evident

Each record stores the hash of the record before it plus a SHA-256 hash of its own contents. Changing any stored field breaks the chain, and the integrity check on the audit screen reports exactly where.

Append-only

Only the server writes audit records, using its service identity. The interface cannot edit or delete a record, and cannot attribute one to another account: it can only ask the server to record an event for the signed-in account, and the server resolves the actor, the institution, the category and the timestamp.

Readable by the right people

Your institution sees its own trail; each member also sees their own activity. Administrators can read across institutions for support and compliance work, and that reading is itself a recorded event.

12 months active, then archive

Audit records stay in the active tier for twelve months and are then moved into the archive tier by a nightly scheduled job. Archived records remain in the trail as evidence but drop out of the default view; your audit screen has an Include archive switch when you need them.

Nothing is deleted by the interface

The trail is append-only: no role can edit or delete a record through the app, and the retention job only ever changes the archive flag. That is what makes the trail usable as evidence rather than as a log that can be tidied up.

Erasure that means erasure

A workspace owner can erase the workspace’s data: every project record is removed, and the payloads held in device storage are cleared on the device that ran the erasure. Other members’ browsers keep their own local copies until they sign out or switch account. The audit record of the deletion stays — that record is the evidence that the deletion happened.