Permissions reference

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 a member reads everything: tasks, reviews, diffs, findings, “Ask” conversations, research, audits. The permissions below concern actions only.

Summary table

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.

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.

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. Also, only the owner can appoint other owners.