Monitoring
Roles and permissions
Read-only is a real role, and it is enforced once at the door rather than screen by screen.
Members can see everything on the account and change nothing. Admins and owners can create, edit and delete. That is the whole model, and its simplicity is what makes it safe to give an account to everybody who wants to look at a result.
It is enforced in one place, at the point every authenticated request passes through, rather than route by route. An unknown role is denied rather than allowed. That matters more than it sounds: a permission model applied per screen is a model where the next screen somebody builds is quietly the exception, and nobody finds out until it matters.
There is exactly one carve-out, and it is deliberate: a read-only member may mark their own notifications seen or read. A notification badge somebody cannot clear is not a badge.
Authentication and authorisation are kept apart on purpose. Whether a role may write at all is one question, answered centrally. Whether a particular experiment or website belongs to you is a different one, checked per resource. Merging them is how a model becomes impossible to reason about.