---
id: governance.reviewer-project-access
title: Reviewer and Project Access
summary: Route reviewers and project participants to the work they are qualified to inspect or approve.
kind: reference
product_area: governance
status: stable
updated: 2026-09-07
canonical: /docs/governance/reviewer-and-project-access
---

# Reviewer and Project Access

## Definition

Reviewer access combines several explicit boundaries. Organization roles are managed in the Admin Console. Project membership determines access to a particular project. Expert Contribution assignment determines which scoped work an expert receives. Artifact approval authority belongs to the owning workflow and must not be inferred from a general role label.

## Fields, states, or lifecycle rules

- A workspace or organization role does not automatically prove access to every Project.
- Project membership does not automatically assign a person to every Expert Contribution.
- Assignment makes work available to the intended expert; it does not pre-approve the expert's response.
- Checkpoint and artifact approval state must be read from the Contribution or governed object itself.
- Removing access can prevent future interaction without erasing already recorded attributable evidence.
- API keys, service scopes, and customer integrations are separate authorization boundaries.
- Exact permission keys and enforcement behavior should be read from current administration and project surfaces, not inferred from persona names.

## Related objects

Use [Admin Console](/docs/admin-console) for organization roles and directory controls, [Project Members](/docs/project-settings/project-members) for project participation, and [Expert Contributions](/docs/expert-contributions) for assignment and expert-runtime state. Use the owning Policy, Rubric, Case, or Contribution page to determine approval.

{% example-demo title="Qualified expert without project access" %}
A specialist is the right reviewer for a source-authority Contribution but cannot open the assigned task. The operator checks organization membership, then Project membership, then Contribution assignment. Granting the missing Project access makes the task reachable; the assignment still controls which work is presented, and the specialist's later Checkpoint decision remains a separate recorded action.
{% /example-demo %}

## Source confidence

Code-backed: Project Permissions, Project Members, user, and workspace types establish project participation and role presentation. Contribution pages define assignment, runtime, and approval state separately; this page does not claim a complete authorization matrix.

## Related task pages

{% related-card-grid title="Related task pages" %}
- [Roles and Permissions](/docs/governance/roles-and-permissions)
- [Reviewer Assignments and Statuses](/docs/expert-contributions)
- [Permissions](/docs/reference/permissions)
- [Product quickstart](/docs/quickstart)
- [Task index](/docs/operating-manual/task-index)
{% /related-card-grid %}