How access is decided
Every access decision asks two questions, and both must pass: does this person hold the permission, and does their role allow it in this context. A permission alone is not enough for a sensitive mutation, and a role alone never is.
Why it works this way. A role is a job title and job titles drift. Tying an irreversible action to a title alone means the action quietly follows the title wherever it goes. Naming the permission keeps the decision explicit.
What each role can do
| Role | Typically holds | Cannot |
|---|---|---|
| Founder / super admin | Platform-wide oversight, governance decisions | Bypass a governance approval that requires a second person |
| Organization admin | Programmes, projects, team, integrations, retention | Reach another tenant's data at all |
| Research / M&E | Studies, sampling, analysis, qualitative coding, reports | Change retention policy or consortium access |
| Data analyst | Run analyses, read evidence, build reports | Create studies or configure integrations |
| Quality reviewer | Review evidence, confirm codings, promote results | Author the analysis they are reviewing |
| Enumerator | Assigned collection work, uploads, sync | Create a study, run an analysis, read another project |
Sessions and revocation
An SSO session is the same session object as a password session — created by the same code and revoked by the same code. Deactivating a user ends their ability to authenticate and refuses their existing sessions.
Tenant isolation
A request for another organization's object returns not found, never forbidden. That is deliberate: "forbidden" would confirm the object exists, which tells you something about another customer's data.