Member Roles & Permissions

EvidAI uses a four-role model designed for systematic-review teams. The roles map cleanly to research-team realities (PI, project manager, screener/extractor, methodologist or auditor) and the permission grid is designed to keep blast radius small.

The four roles

Owner

The person who created the workspace, or whoever has been promoted to Owner since.

• Full access to every feature
• Can invite, promote, demote, and remove other members
• Can change billing, change plan, cancel subscription
• Can transfer Owner status to another Admin
• One Owner per workspace at a time

Admin

A trusted operator who runs the workspace day-to-day without billing reach.

• Full access to every review and every team feature
• Can invite, promote (up to Admin), and remove other members
• Cannot change billing or transfer Owner status
• Cannot remove the Owner

Reviewer

The default role for collaborators who are doing the actual work.

• Can be assigned to any review
• On reviews they are assigned to: full read/write — protocol, screening, extraction, risk-of-bias, synthesis, manuscript
• On reviews they are not assigned to: read-only access for context (no edits)
• Cannot invite or remove team members
• Cannot change billing

Auditor

A read-only role for methodologists, regulators, or external reviewers who must verify but not modify.

• Read-only access to every review they are explicitly granted
• Can download audit trails, export bundles, and reviewer-note digests
• Cannot make screening decisions, extract data, or sign off on phases
• Cannot invite team members

Permission matrix

Why this shape

EvidAI follows a least-privilege model:

• Reviewers get full edit power, but only on reviews they are assigned to. This prevents a screener from accidentally editing somebody else's protocol while still giving them the read access they need to learn from prior work.
• Auditors are deliberately walled off from edit operations. This is the role you give a regulator, an HTA reviewer, or an external methodology consultant who must inspect the trail without altering it.
• Admin exists so the Owner can step away from day-to-day operations without losing oversight.

Changing somebody's role

In Team Hub, click the role badge next to a member and pick a new role. The change is instant, audit-logged, and reflected everywhere (assignment picker, audit page filters, Enterprise Command Center tiles) within seconds.

Best practices

• Promote sparingly. Default new joiners to Reviewer. Promote to Admin only after they have demonstrated they understand the workflow.
• Use Auditor for outside parties. Methodology reviewers and HTA submission reviewers should always be Auditors, never Reviewers — they need read access without the ability to alter results.
• Document role changes. Use a reviewer note when you promote/demote so the audit trail records the why, not just the what.