Research the way you already do. The system keeps the rules.

Researchers work as they do today, in a VS Code–compatible editor in the browser with a coding agent. The system decides and records which data they can see, who can see their results and where each result came from.

Example: choosing data changes who can see the results

Choose the data. Who can see the results changes with what you choose. This picture is an example: in a workspace with chest CT and patient basics, adding lab values narrows who can see the results from 4 to 2.

App in development
Data this workspace uses

images

tables

Releases

Visible files
1,252
New workspace for kim31 people, 6 roles

Who can see this workspace's results

4 of 31 people

one of ct_research or imaging_all and one of ehr_basic or ehr_full

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

Admins can always see

Example dataPreview: /tables/labs
Command to run: ws create kim --data /images/ct_2024 /tables/patients

This is the command the Create workspace button runs.

This is an example, computed from the made-up accounts of a test institution: 31 people and their roles. In the product the server computes this number, and the screen only draws it.

See the roles
DataRoles that may see itPeople
/images/ct_2024 ct_research or imaging_all 9
/tables/patients ehr_basic or ehr_full 14
/tables/labs ehr_full 8
r-0137 The condition of the data it was made from:one of ct_research or imaging_all and one of ehr_basic or ehr_full 4

The other 12 people hold no role that can see any of these four. Not a real institution or person.

The data goes to a laptop, and the agent does the rest

Researchers download data to their own machines and work with a coding agent. It is fast, but nothing records who used which data for what, the same task gives different results in different hands, and results are hard to rebuild.
  • No one can see who uses what
  • The same task gives different results
  • The process leaves no trace
  • Results are hard to rebuild

Systems that make every step a declared pipeline are hard to follow.For rules to hold, the system has to carry them.

Choose, work, release

Researchers do one new thing at the start and one at the end. They choose the data when they create a workspace, and press Release outputs when they share a result. In between, they work as usual.
  1. Step 1: Choose the data

    When you create a workspace, choose the data it uses. You see only data you may use, and only what you choose goes in.

    New workspace App in development
    ws create kim --data /images/ct_2024 /tables/patients
    It follows the data chosen above. This is an example, drawn from the app in development.
    Chosen data /images/ct_2024/tables/patients
  2. Step 2: Work as usual

    Press Open IDE and a VS Code–compatible editor opens in a new tab, with a coding agent ready. Today that agent is Claude Code. Your data is in /data, your code in your work folder.

    When the agent wants to add data or release outputs, it can only ask. The researcher sees what would change, then approves.

    Workspace editor
    My work
    outputs
    reproduce.sh
    train.py
    My data (read-only)
    images/ct_2024
    tables/patients
    This is an example. My work is your work folder (~/project); My data (read-only) is /data, where only the data chosen above appears, read-only.
    Workspace and approved request ws-0012 a-0032Done
  3. Step 3: Release outputs

    To share a result, press Release outputs. The code, the environment and the data behind it are kept with it, and the share link checks permission every time it is opened.

    Release outputs App in development
    release create --workspace ws-0012 --outputs project/outputs/gradcam_018.png project/outputs/metrics.json --reproduce project/reproduce.sh
    The command the Release outputs button runs. This is an example, drawn from the app in development.
    Release r-0138gradcam_018.png

Anyone who may see the release sees this record. The saved work folder and environment open only for the workspace owner and admins.

What release r-0138 keeps

Not re-run yet App in development

This is an example. It follows the data chosen above.

Created by
kim
Created
2026-10-22 11:57
Workspace
ws-0012
Data used
/images/ct_2024/tables/patients
Outputs
project/outputs/gradcam_018.pngproject/outputs/metrics.json
Who can see
4 of 31 people one of ct_research or imaging_all and one of ehr_basic or ehr_full
To reproduce
project/reproduce.shThe reproduce command and the environment at the time are saved. Not yet run again to check.

The same record in a terminal

release show r-0138

Researchers keep their pace. Administrators get answers.

Administrators can answer who used which data, where each result came from, who can see it and how to rebuild it.
Access that follows the data
A result is visible only to people who can see all the data behind it. When a source's permission changes, who can see the results built on it is recomputed.
Results you can trace and rebuild
Each release keeps its code, environment, data and the command that rebuilds it. Re-running to verify is planned.
Agents inside a fence
Each workspace has its own internet rules. When the agent wants to add data or release outputs, it can only ask; the researcher approves.
An installation for your institution alone
It is installed on your institution's server, and one installation serves one institution. Where it runs today and what is planned is listed below.

Read more in How it works

Every button is a command

The command console at the bottom of the screen shows the exact command each button runs, with its output. Copy it and run it again in a terminal: the screen, the terminal and the API follow the same rules.

Sign-in, opening the IDE and the contents of uploaded and downloaded files do not appear in the console. The screens are in Korean and English; commands and the console are in English.

Command console App in development
ws start ws-0012
... 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 --approval a-0031
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_allRan the approved request: a-0031
ws stop ws-0012 Runs when pressed
The command console after starting a workspace and approving the agent's request to add data. This is an example, drawn from the app in development.

Choose who the guide is for

For researchers

There are two new things to learn. Inside a workspace you use a terminal and a coding agent, and you can install packages.

For researchers

For labs and institutions

See how it is installed and what your institution controls: data and roles, accounts and internet rules. Your institution also sees the records.

For institutions

Agents make mistakes. So they work inside a fence.

A workspace reaches only the places an admin allows and holds no database or storage credentials. The security overview says plainly what is protected and what is not.

What it prevents

  • A workspace holds only the chosen files its owner may see, read-only.
  • Traffic leaves only through a proxy, to places an admin has opened. No rule reaches another workspace.
  • When the agent wants to add data or release outputs, nothing runs until the researcher approves.

What it does not prevent

Source data stays on your server. What can leave, and how:

The model provider
What the agent reads goes to the model provider under each researcher's own Claude account.
The editor
People can view and download files through the editor. Each download is recorded.
SSH
People an admin allows can also take files over SSH.
Released results
They go only to the people allowed to see them.

Admins can see all data and results in the installation.

One installation, one institution

Install it on your institution's server. It runs today on NVIDIA DGX Spark. x86 servers and an instance run for your institution alone (SaaS) are planned. Either way, no installation is shared between institutions.

Not released yet. We are preparing the first installation, and no institution runs it yet.

NVIDIA DGX Spark (arm64)Runs today
On your institution's server
x86 serversPlanned
On your institution's server
Dedicated instance (SaaS)Planned
Run by Praesidion for your institution alone

We wrote down how it works

The docs set out what researchers do and what the system does, what your institution controls, and what is and is not protected.