# Permissions

> Who sees the knowledge base, who changes it, and how to grant a member the permission.

The knowledge base has two permissions. Both are set in the [“Members and permissions”](/en/docs/teams/permissions) section.

| Permission | What it gives | Who has it by default |
| --- | --- | --- |
| **View the knowledge base and archive** | Open the section, read entries and the archive | Contributor and Maintainer |
| **Create, edit, archive and restore knowledge** | All editing, entry flags and running a pass by hand | Maintainer |

**The organisation owner** can do everything, always.

## A permission applies by the entry’s scope

Permissions are checked against the [scope](/en/docs/knowledge/scopes) of the specific entry, not against the section as a whole:

- a grant on a **project** allows reading and editing that project’s knowledge (and reading the organisation-wide entries), but **not** changing the organisation-wide ones;
- a grant on the **organisation** covers everything.

The list of entries shows what the member is allowed to read: a member with access to one project opens the section and sees the entries of their project and of the organisation — there is no refusal for the whole section. The “Knowledge base” item itself is shown in the menu only to those who have read permission in at least one scope.

## Why every role can read

The knowledge base defines the model’s behaviour at every stage. A member who sets tasks and works through reviews must understand the rules the AI works by — otherwise its decisions look inexplicable. That is why reading is part of both roles, while writing is not: a rule that reaches every run is set by whoever is responsible for the project.

## What goes into the audit log

Every creation, change, archiving, restoration, flag toggle and clearing of the “needs review” mark is recorded in the [audit log](/en/docs/audit-log): who, when, which entry, **which fields changed** and what the flags were before and after. The model’s entries — created, updated, marked or archived by it at any stage — go there too as pipeline actions, with the stage and the task in the details. **The entry body does not go into the log** — the log is not a store of texts. Reading the section is not logged, like any other read.