Roles and Permissions in Pertento

Pertento separates people who can read from people who can change things, and it applies that separation in one place rather than screen by screen.

The roles

• Member: read only across the whole platform. A member can see every experiment, every result and every report, and change none of it.
• Admin: can write. Building, starting, stopping and deploying experiments are all admin actions.
• Owner: can write, and owns the organisation itself.

Why read only is safe to hand out

A member sees everything and breaks nothing, which makes read only the right default for stakeholders, analysts and anyone who wants to follow a test without being responsible for it. Starting, stopping and rolling out a winner stay with admins and owners.

Where the rule is enforced

The check happens once, at the door, rather than being repeated on each route. This matters more than it sounds: a permission model applied screen by screen is one where the next screen somebody builds is quietly the exception, and nobody notices until it is a support ticket.

Account scope works the same way. What you can reach comes from who you signed in as, not from an identifier in the address bar, so there is no account id in the URL to check and none to tamper with. An agency sees its roster; a single brand customer sees their own account, in the same screen.

The activity log

Every change that matters is recorded against the experiment with who made it and when: targeting added, weights changed, started, ended, deployed. Notifications tell you what happened. The log tells you who did it.

Notes

• Read only means read only: it is not a reduced set of write actions, it is none of them.
• Roles apply platform wide: they are not set per website or per experiment.
• Passkeys are separate: a role decides what you may do, and a passkey decides how you prove who you are.