Concepts

Workspace

Menu: My workspaces

Your working environment for one project: a VS Code–compatible editor in the browser, a terminal, Claude Code and your work folder.

A workspace belongs to its owner and is never shared. You share results by releasing them.

My data

The source data you may see. Admins put roles on data folders, and you see the data that carries one of your roles.

Data you may not see is not listed, and you cannot tell that it exists.

Why it works this wayLists, previews and requests answer the same for data that is missing and data you may not see, so not even a name leaks to someone without access.

Role

A label an admin gives to people and to data folders, such as ct_research. A role on a folder applies to everything under it.

There are no deny rules. Data that must stay hidden goes in a separate folder or a separate table.

Data this workspace uses

The data that goes into a workspace, chosen when you create it. “All my data” is chosen to start with. You can choose folders, tables and colleagues' releases.

You can add to it later, but never take anything out. To start without some data, create a new workspace.

Why it works this wayEach project declares its data in one step, and the system enforces it.

/data

IDE: My data (read-only)

The folder where data appears inside a workspace. It holds only the files you may see and chose for this workspace, and it is read-only.

Nothing is copied: these are the original files. When an admin changes permissions, running workspaces see it at once.

Why it works this wayAn agent cannot read what is not there. Files you may not see are not blocked: they are simply absent.

Work folder

IDE: My work (~/project)

Your own files in a workspace: the whole home folder, ~, with your code in ~/project. Python packages you install and your Claude conversations live here too.

It stays when you stop the workspace or its environment is recreated. Each workspace's work folder has a size limit.

A workspace remembers its data

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 your work folder.

That is why data you added cannot be taken out. The screen says so: “Already in this workspace. To remove it, create a new workspace.”

Why it works this wayRevoking access never launders a workspace: its results stay limited to people cleared for everything it used.

Tables

A table is a folder of Parquet files, such as /data/tables/patients/. The table.yaml in the same folder describes the columns: meaning, units, code systems and missing-value rules.

In a workspace, every table is also ready in DuckDB under its own name, so you can query it with SQL.

Why it works this wayTables are folders rather than one database file, so each table gets its own permissions. When only some columns or rows may be shown, an admin publishes a derived table, such as a de-identified copy, and grants it separately.

Release

Menu: Releases. Button: Release outputs

Releasing turns files from a workspace into a result other people can see and use. You name the files and the reproduce script.

A release never changes, and each has an ID such as r-0139.

Who can see this workspace's results

In tables and dialogs: Who can see

The people who may see all the data this workspace has used. Adding data can make the group smaller.

The screen shows it as a number, such as “4 of 31 people”, and tells you before an addition how the number would change. If nobody would be left, it says “As it is, only admins can see the results”. Admins can always see.

On the screen's strip, each cell is one person. Filled cells can see; hatched cells would no longer see if the data you are pointing at were added. An example:

Why it works this wayIt closes a common leak: a model built from CT images and health records is never shown to someone cleared only for the health records. The system recomputes it whenever permissions change.

Roles needed

The condition behind who can see. It has one or more lines of roles, and a person must have at least one role from each line.

For “one of ct_research or imaging_all and one of ehr_basic or ehr_full”, both lines must be met.

Widening who can see

When a result is safe to share more widely, such as aggregate statistics, an admin can widen that one result, with a reason. The widening is recorded and can be undone.

People who cannot see a release can ask for access from its share page, with a note. The admin grants a role, widens the release, or denies with a note.

What is saved with a release

A release saves, from that moment: the work folder (code, intermediate files, Claude conversations), the environment with any packages you installed, the data the workspace could see exactly as it was, and the reproduce script. The screen says “The reproduce command and the environment at the time are saved.”

Saved work folders and environments are visible to the workspace owner and to admins only.

Today only the reproduce script's existence is checked. Running it again to verify the results is planned, so every release currently shows “Not re-run yet”.

Share link

A release's address. A link is an address, not a permission: each time someone opens it, the system checks whether they may see it now. Once access is revoked, the link stops working for them at once.

Only people with an account on the same installation can open it. Views and downloads are recorded.

Sources

A picture of the data and releases a result came from. Anything you may not see appears without a name, as “Data you cannot see”.

Replaces

When you release a corrected or redone result, choose the earlier release it replaces. The earlier release's page then points to the new one, and the earlier release stays.

Coding agent

Every workspace has the coding agent Claude Code installed, with its version pinned. You connect your own Claude account once, and every workspace uses it.

What the agent reads is sent to the model provider (Anthropic) under your Claude account. Whether conversations may train models follows your own Claude account settings.

Why it works this wayThe system guards against the agent's mistakes and misleading instructions, not against people. The agent sees only this workspace's data, reaches only the addresses allowed for it, and holds no credentials to anything else.

Workspace rules

The same rules for Claude in every workspace: read data from /data, keep code in ~/project and outputs in ~/project/outputs, fix random seeds, write a reproduce script, read a table's description first, and report blocked addresses instead of working around them.

Neither you nor the agent can edit the rules file. Following it is up to the model, so check the results yourself.

Approvals

Inside a workspace, Claude or the terminal can only ask to add data or release outputs. You see what would change (visible files, who can see the results) and press [Approve and run]; the requested command then runs once, as you, exactly as asked. If the files changed after the request, it does not run.

Running code, reading /data and using the allowed internet need no approval. What you do yourself in the portal, [Add data] or [Release outputs], runs at once.

Why it works this wayThe approval is enforced on the server, so an agent cannot skip it.

Internet rules

A workspace cannot reach the internet directly. It goes out only through the rules an admin sets for it, by default Claude and the package repositories (PyPI, Ubuntu apt, VS Code extensions).

Blocked requests show in the internet access log. If you need a blocked address, send it to an admin.

Why it works this wayAdmins open what each project needs: Claude only, packages, the internet, or named internal servers. Changes apply at once, even to running workspaces, and are recorded.

Command console

At the bottom of the screen it shows each button's command and its output, as it runs. You can copy a command and run it again; the History tab lists the commands you ran from the screen, the API or a workspace.

Screen, terminal, API and agents all use the same commands and the same permission checks. Signing in, [Open IDE], and the file contents of uploads and downloads do not appear as commands.

Why it works this wayNothing the screen does is hidden or special, so it can be scripted, audited and taught.

Errors and reasons

A failure says in one sentence what did not work, then gives the reason and the fix. The console shows the same in the CLI's words, with “reason:”.

IDs

Workspaces have IDs like ws-0012, releases r-0139, approval requests a-0031 and access requests q-0007.

Type an ID, a data path or a share link into “Go to an ID or path” (Ctrl+K) at the top of the screen to go to it.

Languages

The screens speak Korean and English, and your choice is kept in that browser only. Commands, the console and the IDE's menus are in English.

Workspace states

You start and stop your workspaces. Nothing stops one because it is idle.

Archive

Buttons: Archive, Restore

Putting a stopped workspace away. It removes the environment, frees its GPU and stops counting toward your workspace limit. The work folder, records and releases stay, and you can restore it.

Storage

Each workspace's work folder has a limit, and you can see its use against that limit. At 80% or more it says “nearly full”. Admins see the whole store, the source data, the releases and every work folder.

Authenticator app

After your password, you enter the 6-digit code from an authenticator app on your phone (Google Authenticator, Microsoft Authenticator and others). When the site is reachable from the internet, every account must set one up.

For accounts with an authenticator app, creating SSH keys or API tokens needs a code from the last 10 minutes. If you lose your phone, an admin resets the app.

SSH

If an admin allows SSH for your account, you can connect to your running workspaces from your own terminal or desktop VS Code. There is no password: only a key you registered gets in.

Why it works this waySSH allows bulk download, so it is off by default and allowed person by person.

API token

A key that lets a script run commands as you. You create it in My account, and its value is shown once, when you create it. It expires after 90 days by default and can be revoked at any time.

Never keep one in a workspace: an agent there could use it to run commands without approval.