> ## 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 9 · Role-Based Access

> This module is the taster — the full deep-dive (personal vs. role vs. org context, persona authoring, provisioning via SSO/SCIM, a six-persona template library) is the Context S… (~20 min)

*This module is the taster — the full deep-dive (personal vs. role vs. org context, persona authoring, provisioning via SSO/SCIM, a six-persona template library) is the [**Context Stack**](/workshops/context-stack/overview) workshop.*

The ontology is just files. The **behavioral context** — what Ana knows, how she responds, what she's allowed to touch — is also just files, in a `behaviors/` folder. Swap the context, swap the persona. The governed `.tql` underneath doesn't change.

```text theme={null}
behaviors/
  program_manager/
    org_context.md    ← restricted scope, plain-language behavior
  analyst/
    org_context.md    ← broad scope, assumption-transparent behavior
```

Each `org_context.md` defines: allowed data surfaces, clarification behavior, response style, and hard limits (what Ana must decline, and how).

## 9.1 · Same question, two personas

Open the ontology with each behavioral context attached and ask the **same broad question**:

```text Prompt theme={null}
[A broad question in your domain — e.g. "How are our patients doing on hospital utilization and cost?"]
```

<Check>
  **You'll see:** **Program Manager:** Ana asks to clarify with a menu of allowed options only, then answers in plain language — no SQL, summary first. **Analyst:** Ana states her assumptions, proceeds, shows the SQL with a clause-by-clause explanation, and flags inference vs. governed surface.
</Check>

## 9.2 · The strong moment — an off-scope request

```text Prompt theme={null}
[As the restricted persona, ask for something outside that role's scope — a domain they aren't provisioned for.]
```

<Check>
  **You'll see:** Ana **declines and redirects** — the data exists and the governed surface exists, but this role isn't scoped to it. The access control lives in the context: auditable, version-controlled, reviewable like any other file.
</Check>

## Common questions

<table>
  <tr><th>Question</th><th>Answer</th></tr>
  <tr><td>How does this relate to our existing RBAC?</td><td>It's the semantic layer of RBAC — above the database, below the UI. Database permissions control which rows exist; behavioral context controls which questions get asked and how answers are framed.</td></tr>
  <tr><td>Who manages the personas?</td><td>The same team that manages the ontology — each is a Markdown file in git: branch, review, approve.</td></tr>
  <tr><td>How many can we have?</td><td>As many as you need — one per team, use case, or compliance boundary.</td></tr>
  <tr><td>What stops someone switching personas?</td><td>Context is provisioned at the org/session level by an admin — tied to your identity provider's groups via SSO/SCIM.</td></tr>
</table>

## 9.3 · Identity folders — routing, not duplication

Access controls decide *what a role can see*. A second, complementary structure decides *where a role's questions land*: **identity folders** — `teams/finance`, `roles/account-executive`, `people/jane-doe`, `customers/acme`. Each holds a short README naming the audience, the recurring questions, and **links to the canonical shared definitions** — never copies of them.

<Warning>
  **The one rule** —

  **Route, don't redefine.** An identity folder's README says "start with `../../domains/finance/revenue`" — it never redefines revenue locally. One governed definition, many doors into it. (This is the same principle as the Context Stack's "one EDM, many personas.")
</Warning>

### ✅ Checkpoint

* [ ] The same question produced two correctly-different answers across personas
* [ ] An off-scope request was declined and redirected — and you can point to the file that did it