Permissions
What each role can do, how project permissions stack on workspace permissions, and how sharing works.
Permissions are enforced at two levels: workspace and project. A user's effective permission on any action is the higher of their workspace role and their project-specific role (if any).
How the stack works
- Workspace role — set on Settings → Workspace.
- Project role (optional) — set on Settings → Project. If unset, the user inherits their workspace role for that project.
- Action check — every server-side action checks the user's effective role against the action's requirement.
So a workspace Owner is implicitly an Owner on every project (no project-level row needed). A workspace Viewer can be elevated to a Member on a single project for focused collaboration.
What each role can do
| Action | Viewer | Member | Admin | Owner | Ontology admin |
|---|---|---|---|---|---|
| View projects | ✓ | ✓ | ✓ | ✓ | ✓ |
| Ask questions | ✓ | ✓ | ✓ | ✓ | ✓ |
| Read sources | ✓ | ✓ | ✓ | ✓ | ✓ |
| View glossary / ontology | ✓ | ✓ | ✓ | ✓ | ✓ |
| Upload a source | ✓ | ✓ | ✓ | ||
| Save a decision | ✓ | ✓ | ✓ | ||
| Run / create a skill | ✓ | ✓ | ✓ | ||
| Create / edit a tracker | ✓ | ✓ | ✓ | ||
| Accept / reject ontology candidates | ✓ | ✓ | ✓ | ✓ | |
| Write to canonical (workspace) ontology | ✓ | ✓ | |||
| Invite / remove members | ✓ | ✓ | |||
| Manage integrations | ✓ | ✓ | |||
| View audit log | ✓ | ||||
| Rename / delete workspace | ✓ |
Sharing artifacts
Most artifacts (sources, reports, trackers, decisions) inherit project permissions by default — every project member can see them.
Cross-project sharing is supported for sources: a source can be marked subscribed in another project, where it stays in sync with the owning project. Read-only — the subscribing project can't modify the source's data.
Note for the team: explicit per-artifact sharing (e.g. "share this single report with one external viewer") is not implemented today. All sharing happens via workspace/project membership. Confirm scope with engineering before publishing the public version of this page.
Denied actions
When you try to do something your role doesn't allow, the platform returns a clear error message (and writes an auth.forbidden event to the audit log). It does not silently ignore the action.
If you think you should have access, your workspace admin can adjust your role from Settings → Workspace.
Tips
- Use project-level roles sparingly. Most teams should run on workspace-level roles only. Project-level overrides are useful when you have one project that needs broader internal access.
- Audit-log your role changes. They show up automatically in the audit log so you can see who changed whose role.
- Workspace owners can do everything. Don't grant Owner unless the person actually needs to manage the workspace.