> ## Documentation Index
> Fetch the complete documentation index at: https://docs.textql.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Module 6 · Provisioning & Identity

> Goal: how personas reach people — admin-assigned, identity-mapped, fail-closed — and where behavioral context sits in the larger access-control picture. (~15 minutes)

**Goal:** how personas reach people — admin-assigned, identity-mapped, fail-closed — and where behavioral context sits in the larger access-control picture.

## 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**](/workshops/ontology-operations/overview), 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_enabled` attribute mapping).- **SCIM group push** — your IdP provisions users *and* their group memberships; groups map to roles; roles carry behavioral context.

End state: a new hire joins the `[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:

<table><tr><th>Layer</th><th>Controls</th><th>Example</th></tr><tr><td>**Database permissions / RLS / connector scope**</td><td>Which **rows exist** for this identity</td><td>The warehouse returns only this region's members</td></tr><tr><td>**Behavioral context (this workshop)**</td><td>Which **questions get asked** and **how answers are framed**</td><td>The persona offers only allowed surfaces, never shows SQL, declines off-scope with a redirect</td></tr><tr><td>**Platform RBAC**</td><td>Which **features and resources** are usable</td><td>Who can create connectors, edit dashboards, review patches</td></tr></table>

They complement, never substitute: behavioral context without data-layer enforcement is politeness; data enforcement without behavioral context is a wall with no signage — technically secure and practically hostile. Defense in depth is all three (data scoping: [**Connect Your Data**](/workshops/connect-your-data/overview); platform RBAC: [**Admin & Governance**](/workshops/admin-governance/overview)).

## 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.

<Frame caption="Personas assigned by admins, mapped to identity groups.">
  <img src="https://textqllabs.github.io/workshops/context-stack/assets/ctx-m5-provisioning.png" alt="Personas assigned by admins, mapped to identity groups." />
</Frame>

### ✅ 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