Roles & permissions
Every member of an org holds exactly one of four roles: Org admin, Tech reviewer, Feature author, or Observer. This is the admin’s reference for precisely what each role can and can’t do, and where you assign and change it.
A role is your single capability level. It travels with you across every project you can reach and decides what you’re allowed to do there: create, comment, approve, or administer. (A separate dimension, your team membership, decides which projects you can see at all; that is covered under roles, teams & project access.)
The cumulative ladder
The four roles form a single ladder, not a grid of independent toggles. Each role can do everything the role below it can, plus more, so a tech reviewer can do everything an author can, and an author can do everything an observer can. You only ever need to know how far up the ladder a member sits.
What each role can do
Read each row as “this, plus everything in the rows beneath it”:
| Role | Can |
|---|---|
| Org admin | The full org. Configure org settings and AI provider/key/model; invite, remove, and re-role members and revoke pending invites; create and manage teams, projects, and services; author norms, safeguards, templates, and personas; delete features. Admins also see every project regardless of team, plus everything the roles below can do. |
| Tech reviewer | Edit, approve, and reject analysis documents and REASONS canvases, deciding at both review gates (and on through partially approved, approved, rejected, and archived). Can also do everything a feature author can, including on features they didn’t author, plus everything below. |
| Feature author | Create features and edit, submit, and version their own features; can’t approve any artifact, and can only modify features they authored. Plus everything an observer can do. |
| Observer | Read every project, feature, analysis, and canvas they have team access to, and comment on any artifact under review. No create, edit, or approve. |
Approval, and rejection, stops at reviewer and admin
Only tech reviewers and admins can approve an analysis or a canvas, the transitions that push a feature past its two human gates. An author can create the feature, write its definition, submit it for analysis, and version it, but the Approve button never appears for them: a separate person has to sign off. The same restriction applies to the two ways a reviewer can decline: Reject and Reject & rework are also reviewer-and-admin-only, so an author or observer can comment on a feature but never end it or send it back to the AI.
This is the no-self-approval consequence in practice: because authoring and approving are different rungs on the ladder, the person who wrote a feature can’t be the one who waves it through. A gate only means something if a second set of eyes clears it.
Assigning and changing roles
Roles are set and changed by an admin from Org settings → Members:
- You pick a member’s role when you invite them by email, and they join with that role the first time they sign in with that address.
- To change someone later, open Org settings → Members and set their role to any of the four; the change takes effect immediately on their next read or write.
- Removing a member from the org revokes their role entirely; revoking a pending invite cancels a role that was never claimed.
Enforced server-side
These limits aren’t just UI niceties. Every member’s role lives on their record inside the org, and REEZN’s server-side permission checks read it on each write: feature creation requires admin, reviewer, or author; editing someone else’s feature or approving an artifact requires reviewer or admin; managing org settings, members, projects, norms, safeguards, templates, and personas requires admin. The interface hides what your role can’t do as a convenience, but even a direct request that slipped past the UI would be refused. The rules are the real boundary.