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

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:

Prompt

[A broad question in your domain — e.g. "How are our patients doing on hospital utilization and cost?"]

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.

9.2 · The strong moment — an off-scope request

Prompt

[As the restricted persona, ask for something outside that role's scope — a domain they aren't provisioned for.]

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.

Common questions

Question	Answer
How does this relate to our existing RBAC?	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.
Who manages the personas?	The same team that manages the ontology — each is a Markdown file in git: branch, review, approve.
How many can we have?	As many as you need — one per team, use case, or compliance boundary.
What stops someone switching personas?	Context is provisioned at the org/session level by an admin — tied to your identity provider’s groups via SSO/SCIM.

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.

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.”)

✅ 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

​9.1 · Same question, two personas

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

​Common questions

​9.3 · Identity folders — routing, not duplication

​✅ Checkpoint

9.1 · Same question, two personas

9.2 · The strong moment — an off-scope request

Common questions

9.3 · Identity folders — routing, not duplication

✅ Checkpoint