User Roles & Permissions

Roles define what each team member can view, edit, and manage within an organization.

User Roles in Aire Labs

Every member of an organization has a role that governs what they can see and do. Roles are set at the organization level and apply across all projects in that organization.

There are three roles: Admin, Member, and Viewer.

Roles

Admin

Admins have full control over the organization. They can manage team membership, configure organization settings, and create or delete any project. Every organization has at least one Admin.

Member

Members can access and work within projects—editing terms, building scenarios, running sensitivity analyses, and using Project AI. Whether Members can create new projects depends on how your organization is configured.

Viewer

Viewers have read-only access. They can browse projects, explore the block tree, and review scenarios and analyses, but cannot make edits or create new content.

Permission Reference

Action	Admin	Member	Viewer
View projects, blocks, and terms	✓	✓	✓
View scenarios and sensitivity analyses	✓	✓	✓
Edit terms and model inputs	✓	✓
Create and manage scenarios	✓	✓
Run sensitivity analyses	✓	✓
Use Project AI	✓	✓
Create new projects	✓	Configurable
Delete projects	✓
Invite and manage team members	✓
Manage organization settings	✓
Change a protected scenario	✓	If listed as an editor

Protected Scenarios

A scenario with no editors listed is unprotected: anyone in the organization who is not a Viewer can change it. Add one or more editors and the scenario becomes protected, so only those listed editors can change it.

Protection covers every route into the scenario, not just one. A listed editor is required to edit the scenario directly, to have Aire AI make a change, to merge a branch into it, to remove overrides, to reparent or delete it, and to run a code block against it. The check runs on the server rather than by hiding buttons, so there is no way around it.

Someone who is not a listed editor keeps working in their own branch as normal. If a change would reach the protected scenario, Aire tells them it is protected and the change does not go through. This includes renaming an inherited term, since that renames it on the protected scenario the term comes from.

What protection is, and is not

Nobody is exempt. There is no implicit bypass for Admins. An Admin who is not on a scenario’s editor list cannot change that scenario.

Anyone except a Viewer can change the list. Admins and Members can add themselves to a scenario’s editor list, or clear it. This is deliberate, because there is no Admin bypass, an organization could otherwise lock itself out of its own model with no way back.

The practical effect is that protection is a guardrail rather than a permission boundary. It reliably stops an accidental edit to a base case, and it records who the intended editors are. It does not stop a colleague who decides to add themselves. Only Viewers, who are read-only everywhere, cannot change the list.

This is default behavior and needs nothing enabled.

Adding Team Members

Team Members sits in the organization menu. Admins manage the roster there directly.

• Invite someone. Send an invitation and choose the role it grants. The invitee receives an email with a link to accept membership and set up access.
• Chase an invitation. Resend one that has not been accepted, or revoke it.
• Change a role. Move someone between Admin, Member, and Viewer.
• Remove someone. Revoke access for anyone who has left.

Managing the roster is admin-only. Members and Viewers can see who is in the organization but cannot change it. If you need a change and are not an admin, ask an admin in your organization, or contact [e-mail] if nobody available has the role.

Organization-Level Access

Access in Aire Labs is scoped to the organization. A role assigned at the org level applies to all projects within that organization—there is no way to grant access to one project but not another within the same org.

If different teams need separate access boundaries, the recommended approach is to use separate organizations. Within a project, protecting a scenario is the one place access narrows below the org role, as described above. Broader project-level access controls are on the roadmap.

Frequently Asked Questions

Can I change a team member’s role? Yes. An admin can change any member’s role from Team Members in the organization menu.

Can I remove a team member from the organization? Yes. An admin can remove a member from Team Members, which revokes their access.

Can a user belong to more than one organization? Yes. Users can be members of multiple organizations and switch between them freely. Each organization has its own role assignment—someone can be an Admin in one org and a Viewer in another.

What happens to a member’s work if they are removed? Their edits and history remain in the project. Removing a member only revokes their access going forward.