Access control

1. Platform superuser — bypasses every check, across all organizations. Reserved for the people operating the platform.
2. Organization staff — full access within their own organization, checked against the organization the request resolved to.
3. Role holders — access to exactly the permissions their roles carry. A role may be marked as granting everything within its organization, or as the owner role.
4. Members — authenticated, portal only.

Permissions are resource:action. Most resources carry create, read, update and delete; many add actions specific to them, such as publish, approve, refund, verify, grade, open, close and export.

Every administrator GraphQL field declares the codename it requires, so the permission is enforced at the boundary rather than inside each resolver. The full list is in the permission catalogue.

Beyond roles, two finer mechanisms exist. A direct grant gives one permission to one person outside any role. A resource policy attaches conditions to a permission, evaluated against the individual record — for instance allowing edits only to records the user created. Conditions combine with and, or and not, and compare against the user, the resource and the request context.

Every access decision is logged with the codename, whether it was granted, and how — by role, by direct grant, by superadmin status, or denied. This is the record for answering why someone could or could not reach a screen.