Permissions
Definition
Permissions describe the user-facing access boundaries that affect projects, reviewer work, settings, Expert UI access, and organization administration. Use this page to decide which access surface to inspect before diagnosing a blocked workflow.
This reference does not turn role labels into a complete public permission matrix. Exact permission behavior should stay tied to source-backed pages and the admin or project surfaces that expose it.
Fields, states, or lifecycle rules
- Project access affects cases, standards, coverage, benchmark work, and project settings.
- Reviewer access affects assigned expert work and reviewer-facing surfaces.
- Organization administration affects members, groups, roles, security controls, API keys, and integrations.
- Role labels in docs should be treated as understandable operating labels, not as exhaustive permission contracts.
- Do not infer auth, security, compliance, tenant isolation, or billing guarantees from this reference.
Related objects
Permissions should be read with Admin Console, Workspaces and projects, Permissions troubleshooting, and Reviewer and project access.
Worked example
Permissions boundary
Start
Behavior input
- Symptom
- A reviewer can sign in but cannot complete assigned case review.
Middle
Judgment into standard
- Permission boundary
- The issue may be reviewer assignment, project access, Expert UI routing, or missing case context.
Result
Interpretation
- Interpretation
- Diagnose access and assignment before changing cases, standards, or benchmark evidence.
Source confidence
Code-backed: Project, user, and workspace types plus Project Permissions and Members surfaces support the user-facing boundaries described here. They do not form an exhaustive authorization matrix; assignment, organization administration, and object approval remain separate product states.