# Permissions reference

> Every atomic permission: what it allows, where it shows in the interface, and what the role gives by default.

A permission is one authorisation for one action. A role gathers permissions into a set; the **“Permissions” → “Advanced”** button shows each permission as a separate switch. The names below are the same as in the interface.

**Own and other people’s.** Actions on a task come in pairs: “own tasks” are those the member opened themselves (they are the author), “other people’s tasks” are those opened by colleagues. By default a Contributor gets “own”, a Maintainer gets both halves.

**Reading is not a permission.** Within their [scope](/en/docs/teams/scopes) a member reads everything: tasks, reviews, diffs, findings, “Ask” conversations, research, audits. The permissions below concern actions only.

## Summary table

| Permission | Contributor | Maintainer |
| --- | :---: | :---: |
| Create tasks | ✓ | ✓ |
| Submit tasks for work | ✓ | ✓ |
| Edit and cancel drafts — own / other people’s | ✓ / — | ✓ / ✓ |
| Answer clarifications — own / other people’s | ✓ / — | ✓ / ✓ |
| Approve the formulation — own / other people’s | ✓ / — | ✓ / ✓ |
| Stop, resume and close — own / other people’s | ✓ / — | ✓ / ✓ |
| Decide on tests — own / other people’s | ✓ / — | ✓ / ✓ |
| Add findings | ✓ | ✓ |
| Resolve and dismiss findings — own / other people’s tasks | ✓ / — | ✓ / ✓ |
| Send for rework — own / other people’s | ✓ / — | ✓ / ✓ |
| Approve and publish PRs/MRs — own / other people’s | — / — | ✓ / ✓ |
| Create research | ✓ | ✓ |
| Change and delete other people’s research | — | ✓ |
| Ask questions | ✓ | ✓ |
| Change and delete other people’s conversations | — | ✓ |
| Run audits and tools preparation | — | ✓ |
| Add repositories and sync the project | — | ✓ |
| View the knowledge base and its archive | ✓ | ✓ |
| Create, change, archive and restore knowledge | — | ✓ |
| View and export the audit log | — | — |

## Tasks

**Create tasks.** The “New task” button on the project home page and “Add task” in the task list; creating a draft. Without the permission the buttons are not there.

**Submit tasks for work.** The “Send for refinement” button in a draft — it starts the analyst and spends the organisation’s balance. The permission is needed in addition to the permission to edit that draft.

**Edit and cancel drafts — own / other people’s.** Editing a draft’s title and text, the “Cancel” button. The author can always edit their own draft; someone else’s draft opens read-only, with a note, without the permission.

**Answer clarifications — own / other people’s.** The form for answering the analyst’s questions in the task card (the “Clarifications” stage). Without the permission the member sees the questions and a note saying who can answer.

**Approve the formulation — own / other people’s.** The “Approve”, “Rework” and “Reject” buttons at the formulation stage. Without the permission the formulation itself is visible, with a note saying who makes the decision.

**Stop, resume and close — own / other people’s.** “Stop run”, “Resume”, “Close” in the task card and in the task row menu in the list. Without the permission there are no buttons or menu.

**Decide on tests — own / other people’s.** The “Broken tests — a decision is needed” panel: “Ignore for this task”, “Ignore permanently”, “Hold”. Without the permission a note is shown instead of the buttons.

## Review

**Add findings.** The “Add your own finding” button in the review findings panel of any task in the scope (while the task is in review).

**Resolve and dismiss findings — own / other people’s tasks.** The “To fix”, “Dismiss finding” and “Edit” buttons on a finding card. “Own” and “other people’s” here refer to the **task**, not to the author of the finding: for their own task a Contributor decides the fate of any findings, including the model’s.

**Send for rework — own / other people’s.** The “Changes requested” button in the review decision: it gathers the “to fix” findings (or a free-form comment) and starts the rework. Spends the balance.

**Approve and publish PRs/MRs — own / other people’s.** The “Approve” button: opens a pull request or merge request in the source repository of every changed module. This is the only permission a Contributor does not have even for their own task — publishing changes the team’s repository. Without the permission both decisions are hidden, and a note says who makes the review decision instead.

## Deep research

**Create research.** The “New research” button and the “Start research” form. Spends the balance.

**Change and delete other people’s research.** Continuing someone else’s conversation (refining the document), renaming and deleting other people’s research from the list. A member can always work on their own research.

## Ask

**Ask questions.** The “New question” button and the form for a question about the project — the code and connected sources. Spends the balance.

**Change and delete other people’s conversations.** Continuing someone else’s conversation, renaming and deleting it. Review discussions inside a task (“Discuss with the assistant”) are shared: any member in the scope can continue them.

## Project

**Run audits and tools preparation.** “Run the project audit”, “Re-run the audit”, “Update outdated”, “Prepare development tools”. Long and paid operations.

**Add repositories and sync the project.** “Add repository…”, “New development project…”, importing a repository through a connector, “Sync” and “Sync all” in the “Repositories” section. Adding a repository and creating a project are organisation-level actions: for them the permission is needed in a grant on the **whole organisation**.

## Knowledge base

**View the knowledge base and its archive.** The “Knowledge base” section, active entries and the archive; the menu item is visible to those who have the permission in at least one scope. A grant on a project opens that project’s entries and the organisation-wide ones. It is part of both roles: the knowledge base shapes the model’s behaviour at every stage, and a member who sets tasks and works through reviews should understand the rules the AI works by.

**Create, change, archive and restore knowledge.** All editing of entries, the “show to the model upfront” and “permanent” flags, starting a pass over the base by hand. The permission is checked against the **entry’s scope**: a grant on a project lets you maintain that project’s knowledge but not the organisation-wide knowledge — for that a grant on the whole organisation is needed. See [Knowledge base](/en/docs/knowledge/permissions).

## Organisation

**View and export the audit log.** The “Audit log” section in the organisation settings: viewing, filters, CSV and JSON Lines export, integrity checks. **Not part of any role**, not even Maintainer — the log contains the addresses and browsers of all members, so the permission is granted explicitly: “Permissions” → “Advanced” → the switch. It applies only in a grant on the **whole organisation**. The typical recipient is a security officer: they read the log without getting permissions on tasks and without becoming an owner. See [Audit log](/en/docs/audit-log).

## What remains the owner’s alone

These are not configurable permissions and are available only to the organisation owner: members and their permissions, billing and the plan, the choice of models, the rental of compute capacity, creating and revoking connectors, setting up [single sign-on](/en/docs/sso). Also, only the owner can appoint other owners.