Members and roles

Every workspace member has one of three roles. Roles map to a fixed set of permissions checked on every request, so what a member can do is exactly what the matrix below says, with no per-member customization.

Roles and permissions

Viewer: read-only access to evidence. Can inspect integrations, incidents, replay results, and repair proposals; cannot change anything.
Admin: full operational control. Everything a viewer can do, plus managing integrations, contracts, outcome rules, running replays, creating and approving repairs, and viewing members.
Owner: everything an admin can do, plus managing members and workspace settings.

Permission	Owner	Admin	Viewer
`integrations:read`	yes	yes	yes
`integrations:manage`	yes	yes	no
`incidents:read`	yes	yes	yes
`contracts:write`	yes	yes	no
`reconciliation:write`	yes	yes	no
`replays:read`	yes	yes	yes
`replays:run`	yes	yes	no
`members:read`	yes	yes	no
`members:manage`	yes	no	no
`workspace:manage`	yes	no	no
`repairs:read`	yes	yes	yes
`repairs:create`	yes	yes	no
`repairs:approve`	yes	yes	no

Two facts worth noticing: admins can approve repairs (approval authority is operational, not administrative), and admin differs from owner only in members:manage and workspace:manage. When a request lacks a permission, the API answers 403 forbidden; a workspace you are not a member of answers 404, deliberately indistinguishable from one that does not exist.

Invite a member

Open Workspace settings → Members.
Enter the email address and choose the initial role.
Send the invitation. An address that is already a member or already has a pending invitation is rejected, and re-inviting an address cancels its previous invitation.

Invitations expire after seven days. The invitee creates their account from the emailed link (their address is fixed by the invitation), chooses a password of 12 to 128 characters, and must verify their email before they can sign in.

Change access

Owners can change another member's role or remove their membership from the member row.
You cannot change your own role or remove yourself from the member row; leaving is a separate, deliberate action.
A workspace always keeps at least one owner: the last owner cannot be removed or demoted, and the API refuses with workspace_requires_owner.
Removing a member ends their access immediately, including any MCP grants they had, because membership is revalidated on every request.

Next steps

Create a workspace: how the first owner gets in.
Keys and credentials: the service credentials, which roles do not govern.