Roles and permissions

The seven organization roles and what each one can do.

LivingContext uses seven organization roles, from full administrative control down to no access. Roles are assigned per member on the Organization page and apply across the whole organization.

The roles

Role	What they can do
Administrator	Everything, including organization administration and billing management
Creator	Create, edit, and publish docs; review and merge change requests; run, approve, and configure agents
Reviewer	Review and merge change requests; approve agent actions; comment; chat with agents — no authoring
Editor	Create and edit docs; open and submit change requests (cannot review or merge); run agents
Commenter	Comment on docs and change requests; read; chat with agents
Reader	Read docs and comments; chat with agents — cannot post comments
No access	Nothing — the member cannot use the organization

Key defaults

• The member who creates the organization becomes an Administrator.
• New invitations default to Editor. You can pick a different role when inviting, and Administrators can change roles at any time.

If your organization predates the seven-role model, legacy roles map automatically: owner and admin become Administrator, and member becomes Editor. No action is needed.

Choosing the right role

Documentation authors — Creator or Editor

Give Creator to people who own the docs end to end: they can draft, review, merge, and approve agent proposals. Give Editor to contributors who should draft and submit but not have the final say — an Editor’s work always needs a Creator, Reviewer, or Administrator to review and merge it.

Approvers who don't write — Reviewer

Reviewer is built for team leads and admins who gatekeep changes without authoring. They can merge change requests and approve agent actions, including any side-effecting agent action, but they can’t create or edit docs themselves.

Stakeholders — Commenter or Reader

Commenter suits stakeholders who give feedback on drafts. Reader suits everyone who just consumes the docs. Both can chat with agents to ask questions grounded in your documentation.

Suspending someone without removing them — No access

No access keeps the member on the roster but blocks all use of the organization. It’s useful for offboarding in stages or pausing a contractor’s access.

How permissions show up in the product

• Docs and change requests — members below Editor see docs read-only; merge buttons only appear for roles that can merge.
• Agents — running agents requires Editor, Creator, or Administrator; approving agent actions (including anything that changes an external system) requires Reviewer, Creator, or Administrator; configuring agents requires Creator or Administrator. See Agents.
• Inbox — triaging agent proposals in the Inbox follows the same review permissions as change requests.
• Comments — Commenter is the lowest role that can post; Readers see comments without being able to reply.
• Billing — usage and plan information is visible from Editor up; only Administrators can change the plan or seats.
• Organization admin — only Administrators see member management, invitations, and organization settings.

Every organization needs at least one Administrator. Plan role changes so you never lock yourself out of member management or billing.