Security & governance

Exporting results

Guide

How results leave the platform - through a controlled workflow with review and authorization.

In short

Outputs do not leave freely. Export requests are reviewed and validated before anything leaves, so sensitive data cannot leak out.

Why export is controlled

Everything inside a workspace stays there by default. Nothing leaves unless someone approves it leaving - that is the rule the whole environment is built around.

Every other control exists to make export the only way information gets out. Isolation, access control, no downloads to your machine: all of it narrows the exits down to one door, so that one door can be watched properly.

What the review is actually looking for

Not whether your analysis is good - whether the output could identify someone.

Results derived from personal data can carry traces of it. A frequency table with a cell containing one patient. A scatter plot where an outlier is a person. A model that memorised its training data. Each is a summary, and each can leak.

So the reviewer asks: could anyone, given this output and whatever else they might know, work out something about an individual? And: is releasing this within what the project agreed?

The export workflow

1. Request an export

   From your workspace, submit an approval request describing the output you want to release. This happens inside the platform - there is no paper form and no external process. Ask for what you need rather than everything you produced; a smaller, clearer request is reviewed faster.

2. Review

   The request is checked against the project's governance and for disclosure risk. The reviewer is normally the principal investigator, or someone they have delegated it to - in platform terms, whoever holds the data-manager role in that workspace.

3. Decision

   The reviewer approves the export, rejects it, or asks for a change. If the disclosure risk is unclear, they escalate rather than guess - to whoever runs your instance, and to a data protection officer where needed.

4. Release

   Approved outputs are released to you outside the environment, and the decision is recorded whichever way it went. Anything not approved stays in the workspace, where you can still work with it.

What may leave, subject to review

These are the outputs a project would normally expect to release. Each still passes through review - "allowed by default" means the reviewer starts from yes, not that the check is skipped.

• Aggregate tables
• Descriptive statistics
• Figures
• Reports
• Code, provided no sensitive data is embedded in it
• Synthetic or anonymised examples, where the project has approved them
• Model metrics and documentation

What does not leave by default

These need a specific, argued case - and some cannot be released at all:

• Raw individual patient data
• Direct identifiers
• Records granular enough to be re-identifiable
• Small counts below the agreed threshold
• Unreviewed extracts of free text
• Model artefacts - weights, checkpoints, embeddings, derived features
• Images or media derived from patients, unless specifically reviewed
• Unreviewed output from generative models

A trained model is not a summary

It is easy to assume a model is safe to release because it contains no records. It can be attacked: inference and reconstruction techniques can recover things about the data it was trained on. So model weights, embeddings and derived features are treated as potentially sensitive information, and leave only after a review that looked at that specific risk. Plan for this before you promise a model to a collaborator.

The scientific side of a model - how it was validated, versioned and made reproducible - remains the project's own responsibility. The platform governs what leaves, not how the research was done.

Working with the review rather than against it

This is the step researchers most often plan for last, and it is the one that takes longest. A few habits make it painless:

• Export as you go, not in a rush at the end. A rejected request at the end of a project is a real problem; the same rejection in month two is an afternoon.
• Ask for the specific output, not the folder it lives in.
• Aggregate before requesting where the analysis allows it - fewer disclosure questions to answer.
• Keep the raw work inside. There is no need to export intermediate data you are still analysing; the workspace is where that belongs.

Before a project closes

Anything you need to keep has to be exported while the workspace is still open. Review takes time - do not leave it to the final week.

<- Previous

Data access model

Next ->

Rules of use