Two things for the researcher. The rest is the system's job.

Not released yet. The screen drawings are examples copied from the portal app in development; the commands and their output come from the CLI, which works today.

The workspace: a VS Code–compatible editor and a coding agent in the browser

Each workspace has its own environment. A VS Code–compatible editor (code-server) opens in a new browser tab, with a terminal and a coding agent ready.

The agent installed today is Claude Code, as a command-line tool and a VS Code extension. Its version is pinned and auto-update is off, so the environment saved with a release keeps the exact version.

There are two folders: your work in ~/project, and your data, read-only, in /data.

Closing the tab does not stop what runs in the terminal; reopen it and the same terminal is back. The work folder stays when the environment is recreated. Python packages (pip install --user) live in the work folder, and system packages (sudo apt-get install) are recorded and installed again when the environment is recreated.

The workspace editor

EXPLORER

My work

outputs

reproduce.sh

train.py

My data (read-only)

images/ct_2024

tables/patients

An example drawing of the editor's explorer. My work is your work folder (~/project); My data (read-only) is /data.

While you choose data, you see who can see the results

A result can be seen only by people who can see all the data its workspace has seen. So the wider you choose, the fewer people can see the results.

As you choose, the number of people who can see this workspace's results changes. Rest the pointer on a piece of data, and the people who would no longer see the results are hatched before you add it.

The server computes the number from the permissions (the command is ws preview); the screen only draws it.

New workspace App in development

Data this workspace uses

(partly chosen)All my data
(chosen)/images/ct_20241,248 files
(chosen)/tables/patients4 files
(not chosen) (previewing)/tables/labs4 files

Visible files1,252

Who can see this workspace's results

4 of 31 people

Admins can always see

Adding this data narrows who can see the results from 4 to 2: /tables/labs

Roles needed one ofct_researchorimaging_all and one ofehr_basicorehr_full

Name (optional) A name to find it by in your list.

Create workspace

Runs when pressed

$ ws create kim --data /images/ct_2024 /tables/patients

The pointer rests on /tables/labs: the two people who would no longer see the results are hatched. This is an example, drawn from the app in development.

Why adding data narrows it

Each piece of data has its own audience, and a workspace's results go only to people who may see everything it chose. In the example, 9 people may see the CT images and 14 may see the patients table, but a result built from both goes to the 4 who may see both. Add the labs table and it narrows to 2.

This is what keeps a model built from CT images and health records away from someone cleared only for the health records.

How the count is worked out

Only /images/ct_2024

9 people

Only /tables/patients

14 people

Both

4 people

Both, plus /tables/labs

2 people (was 4)

Example data and 31 imaginary people. Each cell is one person, in the same place on every row. Hatched cells are people who would no longer see the results once one more piece of data is chosen. Admins can always see.

Data you may not see does not exist for you

A workspace's /data holds only the files you may see and chose for this workspace, read-only.

Nothing is copied: the workspace sees the original files. Data you may not see is not blocked; it is simply not there. It is not listed, and choosing or requesting its path gets the same answer as a path that does not exist. An agent cannot read a file that is not there.

When an admin changes permissions, running workspaces see the change in /data at once, without a restart.

Terminal

$ ws create kim --data /images/mr_brainCould not create the workspace. Not found: /images/mr_brainreason: No such path: /images/mr_brain. List your data with: lake ls

Here kim has no permission on /images/mr_brain. The answer is the same as for a path that does not exist.

Data can only be added

A workspace remembers every piece of data it could ever see. Even if a file later disappears from /data, something made from it may still sit in the work folder. So revoking access never clears a workspace: its results stay with the people who may see everything it touched.

To start without some data, create a new workspace. The screen says the same: “Already in this workspace. To remove it, create a new workspace.”

The agent asks. The researcher approves.

The agent in a workspace can write and run code and read /data. To add data or release outputs, though, it can only ask.

The researcher opens the approval link the agent hands over, sees what would change (visible files, and how many people could see the results) and approves. The approved command runs once, as the researcher, exactly as requested. If the files changed after the request, it does not run.

The server enforces the approval, so the agent cannot click through it. What researchers do themselves in the portal, adding data or releasing outputs, runs at once.

Approvals App in development

Request to add data a-0031

Claude wants to add data to this workspace.

Workspace: ws-0012
Data to add: /tables/labs (4 files)

What changes
When	Visible files	Who can see
Now	1,252	4 of 31 people
If approved	1,256	2 of 31 people

Command to run

$ ws add-data ws-0012 /tables/labs

Approving runs the command above once, as kim.

If files change or are added after the request, approving does not run it.

Approve and runReject

The page behind the approval link the agent hands you. This is an example, drawn from the app in development.

Workspace terminal (the agent does the same through its MCP tools)

$ synapse ws request add-data /tables/labsRequested approval: a-0031Data to add: /tables/labsVisible files: from 1,252 to 1,256Who can see this workspace's results: from 4 to 2 of 31 people. Admins can always see.It runs after the researcher approves it in the portal: https://app.example.org/approve/a-0031

Internet rules per workspace

A workspace cannot reach the internet directly. It goes out only through a proxy, under the rules an admin sets for that workspace. Changed rules apply to running workspaces at once, and each change is recorded.

A workspace cannot look up internet names (DNS) itself. No rule reaches other workspaces or the portal.

Claude only: The Claude API only
Packages (default): The Claude API, PyPI, VS Code extensions (Open VSX) and Ubuntu apt
Internet: The whole internet on every port, without the internal network
Fully open: The internet and the internal network, every port
Extra rules: Open more for one workspace: a domain, a port, an address or a range, such as an in-house model server. Institutions can add their own templates too.

Admin terminal

$ ws net set ws-0012 --allow huggingface.coInternet rules: Packages (packages)Extra rules:    huggingface.coAllowed:        api.anthropic.com, pypi.org, files.pythonhosted.org, open-vsx.org, openvsx.eclipsecontent.org, ports.ubuntu.com, archive.ubuntu.com, security.ubuntu.com, huggingface.coApplied to the running workspace now.

The same rules in every workspace

Every workspace gives its agent the same rules file. Neither the researcher nor the agent can edit it, not even as root with sudo inside the workspace.

Read data from /data, and do not copy source data elsewhere.
For a table, read its description file (table.yaml) in the same folder first.
Keep code in ~/project and write outputs to ~/project/outputs.
Fix random seeds.
Write the commands that rebuild the outputs to ~/project/reproduce.sh.
If something is blocked, do not work around it; tell the researcher.
Add data and release outputs only by request.

The rules are instructions to the agent. What the system enforces is that the file cannot be edited, and that a release checks that the reproduce file exists. Open the reproduce file (reproduce.sh) before you release to see whether the agent followed them.

Releasing keeps what it takes to rebuild the result

To release, you name the files and the reproduce command file. The environment pauses for a moment, and that moment is saved with the release.

Released files: Copied into the release, with each file's size and SHA-256 hash. Only people who may see the release can open and download them.
Work folder: Code, intermediate files, checkpoints and the conversation with the agent (~/.claude), as they were at that moment. Visible to the workspace owner and admins only.
Environment: The environment as it was, including system packages you installed. Visible to the workspace owner and admins only.
Data used: Everything the workspace could see so far, and the data versions it went through. Nothing is copied; those versions are held so they cannot be deleted.
Reproduce command: The file with the commands that make the outputs again. Today the release checks only that it exists; it does not run it.
Re-run checkPlanned: Running the reproduce command again to check for the same result is planned. Today every release says “Not yet run again to check.”

Not kept: the memory of running processes and what the terminal showed. A workspace that never started has no saved environment.

Command console App in development

$ release create --workspace ws-0012 --outputs project/outputs/gradcam_017.png project/outputs/roc_curve.png project/outputs/model.pt project/outputs/metrics.json --reproduce project/reproduce.sh

Done

... Recording the input data... Saving the work folder and environment... Working out who can see it... Registering the outputsReleased: r-0137Who can see this release: 4 of 31 people. Admins can always see.Condition: one of ct_research or imaging_all and one of ehr_basic or ehr_full

The command console after Release outputs. Progress shows in muted lines; at the end come the release ID and who can see it. The line that gives the length of the pause is left out. This is an example, drawn from the app in development.

A share link is an address. Permission is checked each time.

Every release has a share link (/r/<release ID>). Whoever gets the link still needs permission to open it.

People who may see the release get previews (images, the first rows of tables, metrics), a summary and its sources; model weights show only their file details. People who may not see it get the roles needed and can ask an admin. Views and downloads are recorded.

When a source's permission changes, who can see the releases built on it is recomputed, and the change stays in their history. Revoke a permission and the link stops working for that person at once.

A colleague who pastes the link to the agent in their own workspace turns it into a request to add that release as data.

Release r-0137 App in development

Preview Image roc_curve.png

project/outputs/gradcam_017.pngImage
project/outputs/roc_curve.pngImage
project/outputs/model.ptWeights
project/outputs/metrics.jsonMetrics

Summary

Created by: kim
Workspace: ws-0012
Data used: /images/ct_2024, /tables/patients
Who can see: 4 of 31 people
To reproduce: project/reproduce.sh

Not yet run again to check. The reproduce command and the environment at the time are saved.

Downloads are recorded

What someone who may see the release gets when they open its share link. This is an example, drawn from the app in development.

Release r-0137 App in development

Release r-0137

To see this release you need these roles, at least one from each line.

Roles needed

one of ct_researchorimaging_all Met
one of ehr_basicorehr_full Not met

Note to the admin (optional)

Ask an admin

What someone without permission gets from the same link. The release's files and details stay hidden. This is an example, drawn from the app in development.

Widening, and access requests

When a release is safe to share more widely, an admin widens that one release with a written reason: aggregate statistics, for example, or outputs that contain nothing from some of the data the workspace saw. The widening is recorded with its reason and can be undone.

People who are denied can ask for access from the share page, with a note. The admin grants a role, widens the release, or denies with a note the requester sees.

In the sources of a widened release, a source the viewer may not see appears without a name, as “Data you cannot see”.

Sources: r-0101 App in development

An admin widened who can see it.

An admin widened who can see this release, with a written reason. The source this viewer may not see is hatched and has no name. This is an example, drawn from the app in development.

The command an admin runs to widen it

$ release relax r-0101 --clause ct_research imaging_all --reason 'The lung masks were made from the CT images only and contain nothing from the MR images.'

The screen, the terminal and the API run the same commands

Every button runs one command. The command console under the screen shows that command and its output as they are; copy it and run it again in a terminal.

The exceptions are signing in, opening the IDE, and the file contents of uploads and downloads.

Programs with an API token, the synapse command inside a workspace and the agent's tools run the same commands through the same permission checks. So everything the screen does can be scripted, audited and taught.

The screens speak Korean and English; commands and the console are in English.

CLI reference

Command console App in development

$ ws start ws-0012 Done

... Preparing the workspace network... Checking the internet proxy and gateway... Starting the environmentStarted workspace: ws-0012IDE: https://app.example.org/ws/ws-0012/open

$ ws add-data ws-0012 /tables/labs Done

Added data: /tables/labs (1,256 visible files)Who can see this workspace's results: 2 of 31 people. Admins can always see.Condition: ehr_full and one of ct_research or imaging_all

$ ws start ws-0009 Failed exit code 1

Could not start the workspace. The running workspace limit is reached.reason: 2 workspaces are running or were left running: ws-0007, ws-0012 (limit 2). Stop one (an ended one counts too), then try again.

An example of the command console after Start and Add data. The third command failed at the running-workspace limit. This is an example, drawn from the app in development.

The admin console

Admins work with the data lake (folder tree, uploads, role checkboxes), accounts and roles, all workspaces, internet rules and the access log, release admin, and the audit log.

The admin screens are being built. The commands they will run work today.

Screen: In developmentCommands it runs: Runs today

Screen	Commands it runs
Data lake	`lake lslake addlake grantlake revokelake rm`
Accounts and roles	`synapse user addsynapse user add-rolesynapse user disablesynapse role add`
All workspaces	`ws lsws stopsynapse storage`
Internet rules	`ws net setws net showws net log`
Release admin	`release relaxrelease access grantrelease access deny`
Audit log	`synapse audit`

Data lake App in development

images
ct_20241,248 files
mr_brain
tables
patients4 files
labs4 files

Roles of /images/mr_brain

(not given) ct_research
(not given) ehr_basic
(not given) ehr_full
(from a folder above) imaging_all From a folder above: /images
(given) mr_research To grant
(not given) pathology

Commands to apply (1)

$ lake grant /images/mr_brain mr_research

Apply

Ticking a role stages a command; Apply runs it. Roles given on a folder above are gray and cannot be removed here. This is an example, drawn from the app in development.

Built on widely used open source

What we built is the permissions, the records, the commands and the glue between them. Widely used open source does most of the rest; the coding agent is a commercial product.

Environments: Docker with the NVIDIA Container Toolkit
Browser editor: code-server, with extensions from Open VSX
Data and versions: OpenZFS
Internet access: A squid proxy
SSH: OpenSSH, where an admin allows it per person
Tables: Parquet files and DuckDB

Coding agent: Claude Code: Anthropic's commercial product, not open source. Each workspace gets a pinned version.

Where it runs

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.

Read the security overview For institutions