Roles, teams & project access
Access in REEZN has two independent dimensions: your role decides what you can do, and your team membership decides where you can do it, meaning which projects you can see at all.
These two questions are answered separately, on purpose. A role is a single capability level that travels with you across every project you can reach; a team grants reach into specific projects without touching what your role lets you do there. Picture a grid, with roles down one axis and projects across the other, and you have a clean read on who can do what, and where.
- Role: what you can do
- One level per member, set when they’re invited and changeable later. It governs your capabilities (create, comment, approve, administer) and applies uniformly in every project you have access to.
- Team: where you can do it
- A named group of members attached to specific projects. Being on a team that includes a project is what makes that project, along with its services and features, visible to a non-admin in the first place.
The four roles at a glance
Every member holds exactly one of four org roles. Roles are cumulative, so each one includes everything the role below it can do. There is a single ladder of capability, not a grid of toggles to reason about.
| Role | Can |
|---|---|
| Org admin | Everything: org settings and AI config, members and invites, teams, projects and services, norms, safeguards, templates, and personas, plus all below. Admins also see every project regardless of team. |
| Tech reviewer | Edit, approve, and reject analysis documents and REASONS canvases, deciding at each review gate, plus all below. |
| Feature author | Create features; edit, submit, and version their own features; comment on artifacts; plus all below. |
| Observer | Read everything they have project access to, and comment on artifacts. |
How a team grants access
A role on its own grants access to no projects at all. The visibility a non-admin has flows entirely from teams, and it cascades down the hierarchy in one move:
- An admin creates a team, adds members to it, and attaches the projects that team should be able to reach.
- Each member on the team can now see those projects, every service inside them, and every feature created in them, together with the analysis and canvases on those features.
- Drop a project from the team, or remove a member, and that reach disappears just as cleanly. Access is managed in one place, not as scattered per-person grants.
Enforced server-side
Both dimensions are enforced by REEZN’s server-side permission checks, not just hidden in the interface. A member’s role is read from their record in the org and checked on every write; project access is checked against the project’s own access list, which REEZN keeps in sync from your teams automatically. The UI hides what you can’t reach as a convenience, but even a direct request that slipped past the interface would be refused. The rules are the real boundary.