The system holds the rules. The records keep themselves.
Researchers work in a VS Code–compatible editor in the browser with a coding agent, and the system controls access to the data. The records that sharing and rebuilding results need are kept without anyone having to remember them.
Not released yet. We are preparing the first installations. The admin screens are being built; the commands they will run work today.
Questions your administrators can answer
The answers are in the admin commands, the admin screens being built, and the audit log. Anyone who may see a release sees its sources and its reproduce command on its share page.
- Who worked with which data
- Each workspace's data is recorded, and the record never shrinks. It stays even when access is revoked. Command:
ws show ws-0012 - Which data a release came from
- Each release keeps the data and the earlier releases it used, drawn as its sources. Command:
release show r-0137 - Who can see a release now, and when and why that changed
- Who can see it, the condition behind that, and its history (source permission changes, and widenings by admins with their reasons) are kept. Command:
release show r-0137 - How to rebuild a release
- The reproduce command, and the work folder, environment and data versions of that moment, are saved. Re-running to check is planned.
- Who opened and downloaded a release
- Release views, downloads and files downloaded through the editor are in the audit log. Command:
synapse audit --target r-0137 - A lab view for PIsPlanned
- Today these answers are in the admin commands and the admin screens being built. A view where a lab head sees only their own lab is planned.
What your institution controls
Data and roles, accounts, workspaces, the internet, SSH and releases; your institution also sees the records. All of it through the admin screens or commands.
Roles are ticked in the data lake's folder tree. Each tick stages a command, and Apply runs them. Roles given on a folder above show in gray.
Data lake App in development
imagesct_20241,248 filesmr_braintablespatients4 fileslabs4 files
Roles of /images/mr_brain
- (not given)
ct_research - (not given)
ehr_basic - (not given)
ehr_full - (from a folder above)
imaging_allFrom a folder above: /images - (given)
mr_researchTo grant - (not given)
pathology
Commands to apply (1)
lake grant /images/mr_brain mr_research Apply
- Data and roles
- A role given on a folder or table applies to everything below it, and can be added on a single file. There are no deny rules: data to keep apart goes in its own folder, or in a derived table such as a de-identified copy with its own roles. Command:
lake grant /images/mr_brain mr_research - Accounts
- Create accounts, give roles, issue temporary passwords (72 hours), disable. Disabling stops the account's workspaces and removes it from every count of who can see a release. Command:
synapse user disable kim - Workspaces and resources
- See all workspaces and storage use. Set a GPU memory limit per workspace. How many workspaces one person may have is an installation setting (by default 10 not archived, 2 running). Command:
synapse storage - Internet rules
- Per workspace, a template (Claude only, Packages, Internet, Fully open) plus extra rules. They apply at once, and recent connections, allowed and blocked, can be viewed per workspace. Add templates of your own. Command:
ws net set ws-0012 --template claude-only - SSH
- Allowed per person. As the screen says when you allow it, SSH lets that person download their workspaces' files in bulk (scp, sftp). Command:
synapse user set kim --ssh - Releases
- Widen who can see a release, such as aggregate statistics, with a written reason, or undo it. Answer access requests by granting a role, widening the release, or denying with a note. Command:
release access ls - Audit log
- Append-only. Sign-ins, commands run from the screen, the API and workspaces (refusals included), opens of workspaces and releases, downloads, editor file transfers and permission changes. Command:
synapse audit - Branding
- Your institution's name and logo. Its color stays in the logo tile and never mixes with status colors. Command:
synapse brand set --logo logo.svg
Deployment
Install it on your institution's server, or have it run as an instance for your institution alone (SaaS, planned). Both are the same software, and no installation is shared between institutions.
- On your institution's serverNVIDIA DGX Spark (GB10, arm64, one GPU) Runs today
- On your institution's serverx86 servers Planned
- Dedicated instance (SaaS)Run by Praesidion for your institution alone Planned
Not released yet. We are preparing the first installations.
What differs per institution, such as storage, internet rule templates, internal network ranges, per-person limits and the institution's name, is configuration.
What it runs on
- Server
- One Linux server with systemd. The machine it is tested on today is an NVIDIA DGX Spark.
- Environments
- Docker with the NVIDIA Container Toolkit
- Storage
- One OpenZFS pool for source data, releases and work folders. Production uses real disks.
- Addresses
- One portal address, and a wildcard DNS name that gives each workspace its own address
- HTTPS
- A certificate from your institution. Needed before the site faces the internet, and to set up an authenticator app.
- Researchers
- A current browser (Chrome 111, Firefox 113, Safari 16.4 or later), a Claude subscription (Pro, Max, Team or Enterprise), and Claude Code on their own computer to get the token. People allowed SSH need OpenSSH 8.1 or later.
Sign-in and remote access
People sign in with accounts your institution creates. Sign-in can require a code from an authenticator app, and does for every account once the site faces the internet.
- Accounts and passwords
- An admin creates the account with a temporary password (72 hours); the researcher changes it at first sign-in.
- Authenticator app
- The code is asked only after a correct password, attempts are rate-limited, and a used code is never accepted again. For accounts with an app, creating SSH keys or API tokens needs a code from the last 10 minutes. A lost phone needs an admin reset.
- Sessions
- 12 hours at most, and they end after 60 minutes without use.
- Internet exposure
- Through a Cloudflare Tunnel, without opening server ports. Once public, every account needs the authenticator code, HTTPS is required, and API tokens from the internet are refused by default. This is built, but has not yet been switched on in a real installation.
- SSH
- Allowed per person by an admin. Only registered keys get in, with no passwords, and only to the key owner's running workspaces. Before researchers get it, every connect command still has to be checked on Windows and macOS.
- Single sign-on (SSO)Planned
- Identity is checked in one place, so it can be added later.
What researchers need
A browser, a Claude subscription, and Claude Code on their own computer to get the token.
The Claude subscription must be Pro, Max, Team or Enterprise; a free account cannot get the token (Anthropic's documentation, October 2026). Guide: connecting Claude
Today each researcher connects a personal Claude account. So data terms, such as whether conversations may be used for training, follow each person's account settings, and the institution cannot set them. Ask researchers to check those settings.
Researchers get a token on their own computer (claude setup-token) and paste it once under My account. It is stored encrypted. In a workspace it is a read-only file outside the work folder, handed to the Claude process when Claude starts; the file can be read as the workspace user.
- Institution Claude account and LLM gatewayPlanned
- When usage grows, the plan is an institution account whose key stays outside workspaces, behind a gateway that records every call.
Read next
Installation and operations guides come after the first installation. Until then, How it works and the security overview say what the system does and what it does not.