6.1 · Users don’t choose their persona
The rule that makes personas meaningful: behavioral context is provisioned at the org/session level by an admin — end users don’t select their own. The same way a database role is granted, not chosen. A persona a user could swap off is a suggestion, not a control. Mechanically, personas ride on roles: role-scoped context loads for users holding that role (and folder-level access in the ontology can restrict who can even see persona files — covered in Ontology Operations, Module 2). Assignment happens where role assignment happens — Settings → Members for manual, or identity-mapped (next section). The persona file’s content is authored by the ontology/context owners; who gets it is administered by workspace admins. Two responsibilities, deliberately separated.6.2 · Map personas to identity groups
Hand-assigning roles works at ten users and fails at a hundred. The scaled pattern ties personas to your identity provider:- SSO with role sync — IdP group claims map to roles at login (group names matched to role names; the Admin & Governance workshop’s SSO module, and for self-hosted, the
role_sync_enabledattribute mapping).- SCIM group push — your IdP provisions users and their group memberships; groups map to roles; roles carry behavioral context.
[care-management] IdP group → SCIM/SSO assigns the matching role → their first thread already speaks in the program-manager persona — scoped surfaces, plain language, hard limits — with no admin touch. Offboarding reverses identically: leave the group, lose the persona.
6.3 · The semantic layer of RBAC
Where behavioral context sits in the stack — the framing worth memorizing:| Layer | Controls | Example |
|---|---|---|
| Database permissions / RLS / connector scope | Which rows exist for this identity | The warehouse returns only this region’s members |
| Behavioral context (this workshop) | Which questions get asked and how answers are framed | The persona offers only allowed surfaces, never shows SQL, declines off-scope with a redirect |
| Platform RBAC | Which features and resources are usable | Who can create connectors, edit dashboards, review patches |
6.4 · Fail closed
The default posture for restricted personas, in both design and provisioning:- In the file: the allowlist names what’s permitted; everything else is denied — never the reverse. A new surface added to the ontology is invisible to restricted personas until explicitly added to their list.- In provisioning: a user with no mapped group gets the most restrictive default (or no access), not the org-wide default. Unknown identity → minimum surface.- In review: widening an allowlist is a reviewed change (Module 5.3); narrowing one can ship fast. Asymmetry is the point.
Personas assigned by admins, mapped to identity groups.
✅ Checkpoint
- Personas in your org are admin-provisioned — you verified a test user cannot swap their own
- The IdP-group → role → persona chain is mapped (or planned) for at least your two Module 4 personas
- You can draw the three-layer RBAC table from memory and say what each layer catches that the others miss
- Restricted personas fail closed: allowlist-based files, restrictive provisioning default, asymmetric review