How access actually works#
A person is a member of a workspace with one role. The role expands to a set of permissions, and every console surface and every API route is gated on a named permission, not on a role. That indirection matters when you are debugging access: the answer to “why can’t they see this?” is always the name of a missing permission, and the console says which one.
There are seven roles and thirty permissions. A surface you may not read is absent, not empty. You will not see a greyed-out row or a zero. Zero is a claim about the estate; absence is a claim about the reader.
The seven roles#
| Role | Holds | Give it to |
|---|---|---|
| Owner | All thirty permissions, including installation.manage. | The one or two people accountable for the workspace existing. |
| Admin | Everything except installation.manage. | Day-to-day administrators. They can do anything except change the workspace itself. |
| Knowledge manager | Read, write, verify and publish knowledge; manage packs and offboarding; ingest evidence; read fleet, policy, connectors, risk, expertise, workflows and audit. | The person who owns organisational memory. The steward role with authority. |
| Fleet operator | fleet.read, fleet.manage, policy.read, member.read, audit.read, local_agent.use. | Whoever keeps endpoints running. Explicitly cannot mint credentials, revoke, wipe, promote a model, or approve a new source. |
| Reviewer | knowledge.read and knowledge.verify, plus evidence, risk, packs, expertise, policy and connector reads. | Someone who decides claims but does not publish them and does not touch the fleet. |
| Member | knowledge.read, evidence.read, risk.read, pack.read, expertise.read, local_agent.use. | Everyone else. Enough to run the agent, ask questions, and read what has been published. |
| Auditor | Every read in the product (knowledge, evidence, risk, packs, expertise, fleet, offboarding, policy, connectors), plus audit.read. No write of any kind. | Internal audit, compliance, an external assessor during a review. |
Reviewer versus knowledge manager
Both hold knowledge.verify, so both can decide a claim. Only the knowledge manager holds knowledge.publish, so only they can certify one. That is the difference between approve and approve & publish in the review queue, and it is chapter 8’s central distinction.
The four permissions that are split on purpose#
Most permissions come in a read/manage pair. Four do not, and each split exists because two acts that look similar are not similar at all.
- fleet.enroll
- Minting device identity: enrolment tokens, fleet tokens, invites. One fleet token can admit a thousand machines and can outlive your employment. Separated from fleet.manage because renaming a profile and handing out a credential are not the same act.
- fleet.revoke
- The terminal acts: revoking a device or a fog node, requesting a wipe. No admin action undoes any of them. A revoked credential is not reinstated, and wiped local state is gone.
- source.decide
- Answering a device’s request to read a source it is not yet allowed to read. This is the one fleet action that widens a data boundary: approving it means Evodira sees something it did not see before.
- model.promote
- Promoting a model to a ring, and pinning one there. A promotion changes the weights every device in that ring loads on its next reconcile, so it reaches further than any single-device action.
Only owner and admin hold all four. A fleet operator holds none of them, which is the point of that role: at scale, most operators should be able to keep the fleet running without holding the power to end it or grow it.
Adding people#
Open People and roles
Settings → People and roles. It lists everyone with a role in the workspace and their status.
Add a person
Press Add a person, give their email, and choose the role. Choose the narrowest role that lets them do their job. A role is widened in seconds and a leak is not.
Check what they will actually see
Cross-reference section 02. If they are meant to review claims but never publish, that is reviewer, not knowledge manager. If they are meant to run machines but never mint credentials, that is fleet operator, not admin.
Service members are not people
You will see rows like fleet+<uuid>@svc.evodira.local with role MEMBER. Those are fleet service accounts created per deployment profile. Do not delete them and do not change their role.
Checking your own permissions#
The foot of Settings has a YOUR PERMISSIONS block with a count. Expand it for the exact list your account holds. This is the definitive answer when a surface refuses you. The console names the permission it wanted, and this list says whether you have it.
What a refusal looks like
- The surface is missing entirely from the sidebar and the palette. You lack its read permission.
- You can open it but a control states a permission. For example “Publishing needs knowledge.publish” or “Answering a source request needs source.decide”. You have the read, not the write.
- You typed the URL and got a clean refusal naming the permission. That is deliberate: a direct link to a surface you may not see must say which permission is missing, not silently redirect you to the dashboard.
You are done when
Every person who needs Evodira has the narrowest role that covers their job, no human holds owner except the one or two who must, and you can name which permission a refusal is about without guessing.
Something here wrong, missing, or no longer true of the product? Write to hello@evodira.com. Documentation that has drifted from the console is a bug and we treat it as one.