Managing permissions
Organization and project roles, what each can do, strict approvals that separate signing from editing, archived projects, and the governance log.
This page covers day-to-day permission work: assigning roles, separating approval from editing, and auditing changes. For the concepts behind the model, read Roles and permissions first.
Where: organization roles on
/orgs/<org>(Members) · project roles on Project settings → Members ·/p/<project>/settings?tab=members
Organization roles
| Role | Can do |
|---|---|
| Owner | Full control of the organization and every project in it, including deleting the organization and granting the owner role. |
| Admin | Manages members, invitations and every project in the organization; reads the governance log; edits organization settings. |
| Member | Creates projects and works in the projects they belong to, per their project role. |
| Viewer | Sees the organization and its member list. |
Organization owners and admins have implicit full control of every project in the organization — they appear as Org admin on a project without needing a project membership. Everyone else needs an explicit project role.
Project roles
| Capability | Owner | Editor | Approver | Viewer |
|---|---|---|---|---|
| Read all project content | Yes | Yes | Yes | Yes |
| Create and edit content | Yes | Yes | No | No |
| Create baselines | Yes | Yes | No | No |
| Approve requirements, change-request stages, baselines and documents | Yes | Yes, unless strict approvals is on | Yes | No |
| Manage members and invitations | Yes | No | No | No |
| Edit settings, archive, delete | Yes | No | No | No |
The Approver role reads everything and signs off, but cannot edit — the separation of duties a customer or independent reviewer needs. Organization and project roles are independent: an organization member can own one project, and an organization viewer can be an approver on another.
Owners change project roles on Project settings → Members. A project always keeps at least one owner, and an organization at least one owner; only an organization owner can grant the organization owner role.
Strict approvals
Each project has an Approval governance setting, Require explicit approvers, in Project settings.
- Off (default). Editors can approve as well as edit — approval is bundled into editing.
- On. Editors lose every approve right. Only Approvers and Owners (and organization admins) can approve requirements, change-request stages, baselines and documents. Editors keep drafting; designated approvers sign.
Approvals are signed: each records who approved, when, in what role, with a cryptographic signature over the approved content. Approved, baselined and signed artifacts show in gold.
Archived projects
Archiving a project makes it read-only for everyone, owners included, and for the co-engineer and access tokens acting on their behalf. Restore it from Project settings to edit again.
Isolation
You only ever see organizations and projects you belong to. An object in another organization or project is indistinguishable from one that does not exist: links to it return "not found", not "forbidden".
The co-engineer and access tokens
The co-engineer and MCP clients act as you and are bound by your roles. A read-only personal access token can never write, whatever your role; a read & write token adds nothing beyond what your role allows.
Governance log
Membership, role, approval-governance and lifecycle changes land in the Governance log — on the organization page for organization-wide changes, and in Project settings for each project — so you can see who changed whose role, from what to what, and when.
Common scenarios
- Customer sign-off gate. Turn on Require explicit approvers, then give the reviewer the Approver role. Editors keep drafting; only approvers and owners sign.
- Hand off a project. Promote the new lead to Owner, then step yourself down to Editor or Viewer.
- Read-only stakeholder. Give them Viewer so they can follow progress without changing anything.
- Close out a programme. Archive the project to freeze the record while keeping it readable.
Tips
- Turn on strict approvals before formal reviews so approvals come only from people with the authority to give them.
- Review the governance log after sensitive role changes.
- Keep owners and organization admins few. They have full control of every project in the organization.