Roles & permissions

Every member of a team brain holds one of four roles — Owner, Admin, Writer, or Reader — and that role decides what they can do with the vault's contents.

The four roles

Role	Read notes	Write & edit	Manage membership	Consumes a seat
Owner	Yes	Yes	Yes — only the Owner	Yes
Admin	Yes	Yes	No	Yes
Writer	Yes	Yes	No	Yes
Reader	Yes	No	No	Yes

Owner — the person who created the team brain, and the only one who can add members, remove them, or change a role. The Owner's key signs the roster, which is what makes membership tamper-evident.
Admin — a trusted operator with full read and write access. Admin is a stronger label than Writer, but in this version it grants the same practical capability: it does not confer membership management.
Writer — full read and write access to notes. This is the default role a newly added member receives.
Reader — a strict, read-only member (see below).

Only the Owner can manage membership. Adding, removing, and role changes all require the Owner's signing key, because each of them re-signs the roster. If an Admin tries, the operation is refused. Plan for the Owner to be available — or to hand the vault over — before you need a membership change.

You cannot assign the Owner role to someone. Owner is set when the vault is created; the roles you can hand out are Admin, Writer and Reader.

What "read-only" actually enforces

The Reader lock is real, and it is worth being precise about where it bites:

On the client, editing is disabled for Readers.
On the way in, every change carries its author's signature and is checked against the signed roster. A change authored by someone not authorised to write is rejected and never applied to your vault.

A Reader's working copy is ordinary files on their own disk, and nothing stops them editing those files or writing the result into a shared sync folder. What is guaranteed is convergence: their changes never land in anybody else's vault. Rejections are surfaced to you by author and reason, not silently dropped.

Seats

Every member on the roster consumes a seat, whatever their role — Readers included. Adding a member when the roster is already at the licensed seat count is refused, and the message tells you the current count and the limit.

A roster that is already over the count — because it grew before this check existed, or after a plan change — is not invalidated. Existing members keep working; only the next addition is refused.

Choosing the right role

Give someone Writer

The default. When they need to create and edit notes as part of the team's knowledge work.

Give someone Reader

When they only need to see the knowledge — clients, reviewers, and leadership.

Give someone Admin

When you want to mark them as a trusted operator. Note it does not grant membership management.

See how seats work

Every role consumes a seat on the Team tier.

Learn how roles are granted and taken away → Invite & revoke members.

Team brain overview

The section this page belongs to.

Invite & revoke members

How a role is assigned, changed, and cryptographically revoked.

Plans, seats & Enterprise SSO

How seats are counted against your licence.

Encrypted sync

Where a Reader's writes are rejected, and how that is reported.

Glossary: seat & roles

Plain-language definitions for the terms in this table.