Four exclusive workspace roles
A membership holds exactly one of:
Admin does not imply operator. Single-role assignment is the correct provider
configuration; a membership carrying two workspace roles is drift.
How a ceiling is derived
The provider publishes no Bijection permissions at all. A principal’s ceiling comes from the role slug alone, resolved through the committed binding ingrants.json, and the security layer expands that profile into the internal
capability vocabulary — atelier.members.manage, atelier.settings.read,
atelier.actions.execute, and so on — which the provider never sees.
Runtime checks internal capabilities, never role slugs.
grants.json carries only the organization, the role-to-profile bindings, the
trusted attribute bindings, and the expected agent registrations. No capability
arrays. No membership map.
Break glass
atelier.ledger.erase is the one break-glass capability. It is not a provider
permission and belongs to no standing role — the recorded activation is the
grant.
Model roles are not workspace roles
A model’s own role vocabulary is derived from a trusted attribute, never from a workspace role. A clinical model’soversight_lead and the workspace’s
operator are different alphabets that happen to be spoken by the same person.