Roles & permissions
What each role in a workspace can do, at a glance.
Roles decide what a person can do in a workspace. The principal investigator controls membership and the workspace lifecycle; data managers handle data; researchers analyze.
How roles work
A role is a named bundle of permissions. Every role applies at one of four levels:
| Scope | Applies to |
|---|---|
| System | The whole CHORUS installation |
| Platform | Everything on this instance |
| Workspace | One workspace only |
| Session | One running session only |
Workspace and session roles are the ones most people meet. Because they are scoped, holding a wide role in one project gives you nothing in any other - and nothing platform-wide.
Permissions themselves cover a fixed set of capabilities: administering a workspace, moving files in and out, managing services, approving imports and exports, and reading the audit log. Beyond the built-in roles, an administrator can define additional roles at the institution level.
Workspace roles
These are the roles that apply inside one workspace.
| Role | Can | Cannot |
|---|---|---|
| Guest | See the workspace, list files, see the sessions in it - all read-only. | Upload, download or change files; create a session; request or approve an export; manage members. |
| Member | List, upload, download and change files within the approved scope; create and use sessions; launch applications; submit export requests. | Manage members; approve or reject exports; assign roles; delete the workspace. |
| Maintainer | Everything a Member can, plus change workspace settings and manage the sessions in it. | Manage members; approve exports; assign roles; delete the workspace. |
| Data Manager | Govern the data - files, metadata, ingestion - and approve or reject export requests. The only workspace role that can release results. | Manage members; delete the workspace. |
| Admin | Full control of the workspace: create, configure and delete it, manage members and their roles, read its audit log. | Approve exports without also holding Data Manager; reach any other workspace; administer the platform. |
Session roles
Session roles sit alongside workspace roles rather than replacing them.
| Role | Can | Cannot |
|---|---|---|
| Viewer | Open a session read-only and look at existing notebooks and outputs. | Run anything; manage who is in the session; export. |
| Member | Run analyses in the session, use the approved tools, and produce outputs into the workspace. | Manage who is in the session; delete it; bypass the export workflow. |
| Admin | Create, configure and delete sessions, and manage who is in them. | Administer the parent workspace; approve exports. |
How roles are usually combined
Roles do not inherit from one another - they stack. Most people hold one workspace role and one session role.
| Who they are | Roles they typically hold |
|---|---|
| Principal investigator | Workspace Admin + Data Manager |
| Data steward | Workspace Data Manager |
| Researcher | Workspace Member + session Admin |
| External collaborator | Workspace Member + session Admin, in that workspace only |
| Clinical reviewer | Workspace Guest + session Viewer |
The platform has no principal-investigator role of its own. A PI is a workspace Admin - and because only a Data Manager may approve exports, a PI who reviews their project's exports holds both. Which roles exist and what each one grants is configurable, so your instance may differ from the arrangement above.
What an admin can change, and what they must ask for
A workspace admin can adjust, directly and without asking anyone:
- members and their roles
- the workspace's network policy, within the project's approved scope
- whether copy and paste in and out of sessions is allowed
All of it is logged. What an admin cannot self-serve is more compute or storage than the workspace was provisioned with - that goes to whoever runs your instance, who assesses it and arranges it.
Rules that hold whatever the role
- Exports are always reviewed. No role releases results without an approval decision - see Exporting results.
- Roles are scoped. A wide role in one project grants nothing in another, and nothing platform-wide.
- Reaching files in another workspace requires an approved request, not a role.
- Every role change is recorded, with who made it and when.
- Nobody holds more than their project requires. That is what keeps least privilege meaningful rather than aspirational.