---
id: reference.permissions
title: Permissions
summary: Understand the user-facing permission boundaries for projects, reviewers, settings, and expert UI access.
kind: reference
product_area: reference
status: stable
updated: 2026-09-07
canonical: /docs/reference/permissions
---

# 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](/docs/admin-console), [Workspaces and projects](/docs/concepts/workspaces-projects), [Permissions troubleshooting](/docs/troubleshooting/permissions), and [Reviewer and project access](/docs/governance/reviewer-and-project-access).

{% example-demo title="Permissions boundary" %}
Symptom: A reviewer can sign in but cannot complete assigned case review.

Permission boundary: The issue may be reviewer assignment, project access, Expert UI routing, or missing case context.

Interpretation: Diagnose access and assignment before changing cases, standards, or benchmark evidence.
{% /example-demo %}

## 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.

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Admin Console](/docs/admin-console)
- [Workspaces and projects](/docs/concepts/workspaces-projects)
- [Permissions troubleshooting](/docs/troubleshooting/permissions)
- [Expert UI](/docs/integrations/reviewer-workspace)
- [Product quickstart](/docs/quickstart)
{% /related-card-grid %}