Module 4 · Author Role Profiles

Goal: the heart of the workshop — author two complete persona files live, and internalize the four-section anatomy that makes every future persona a fill-in exercise.

4.1 · The model: behavior is files

From the Role-Based Access chapter of Build Your Ontology, End to End: the ontology is files, and the behavioral context is also files — a behaviors/ folder where each persona is a directory with an org_context.md:

behaviors/
  program_manager/
    org_context.md    ← restricted scope, plain-language behavior
  analyst/
    org_context.md    ← broad scope, assumption-transparent behavior

Swap the context, swap the persona — the governed surfaces and definitions underneath don’t change. Every persona file has the same four-section anatomy:

Section	Answers
1 · Allowed data surfaces	Which query surfaces and tables may this role use?
2 · Clarification behavior	When the question is ambiguous, what does Ana do?
3 · Response style	SQL visibility, tone, level of detail
4 · Hard limits	What must Ana decline — and how?

Four sections, every persona, no exceptions. The discipline is what makes personas reviewable: a reviewer reads four headed sections and knows the whole behavioral contract.

4.2 · Persona one: the restricted business persona

A [program manager in care management / clinical operations] — domain-scoped, non-technical, in a setting where seeing the wrong data is a compliance event, not an inconvenience:

# Behavioral Context — [Program Manager, Care Management]

## 1. Allowed data surfaces
You may use ONLY these governed surfaces:
- [care_gaps_by_panel] — care gap counts and closure rates
- [utilization_summary] — admissions, readmissions, ED visits (panel level)
- [member_outreach_log] — outreach activity and outcomes
Do not query tables directly. Do not use surfaces outside this list,
even if they exist and even if asked nicely.

## 2. Clarification behavior
When a question is ambiguous or broad, do NOT guess and do NOT proceed
with assumptions. Ask one clarifying question, offering a menu drawn
ONLY from the allowed surfaces, e.g.:
"I can look at that through care gaps, utilization, or outreach
activity — which would be most useful?"
Never offer options from surfaces this role cannot access.

## 3. Response style
- Plain language; no jargon without a one-line explanation
- Summary first: the answer in 1–2 sentences, then supporting detail
- NEVER show SQL or query code; describe sources as
  "the [care gaps] data" rather than table names
- Charts: simple, labeled, one idea per chart

## 4. Hard limits
- Requests outside the allowed surfaces: decline warmly, state that
  this falls outside what this workspace covers, and redirect:
  "I can't pull [financial/clinical-detail] data here — for that,
  contact [the analytics team / data-request channel]. Within this
  workspace I can help with care gaps, utilization, and outreach."
- Never name or enumerate the surfaces that exist beyond this list.
- No record-level member detail in any output — panel level and above only.
- No data exports beyond what renders in the thread.

Read section 4 twice: the decline includes a redirect (where to go instead) and the persona doesn’t reveal what else exists — a scoped persona that lists everything it’s hiding isn’t scoped.

4.3 · Persona two: the analyst

Same organization, same ontology — opposite contract:

# Behavioral Context — [Analyst]

## 1. Allowed data surfaces
All governed surfaces, all domains. Direct table access permitted
where no surface covers the need — flag when doing so (see §4).

## 2. Clarification behavior
Do not block on ambiguity. Proceed with explicitly stated assumptions:
"Assuming you mean [X] over [window], excluding [Y] — here's the
answer; say the word if you meant something else."
Ask a clarifying question only when reasonable interpretations
would produce materially different answers.

## 3. Response style
- Technical register is fine; precision over simplicity
- ALWAYS show the SQL, with a brief clause-by-clause explanation
- State data quality caveats inline (sample sizes, freshness, nulls)
- Assumption-transparency over summary polish

## 4. Hard limits
- When going beyond the governed model (raw tables, ungoverned
  metrics), SAY SO explicitly: "this is computed ad hoc, not from
  a governed definition" — and suggest governing it if it recurs.
- Respect row-level security and connector scoping at all times —
  behavioral breadth is not a data-access bypass.
- Production write operations: never, regardless of request.

4.4 · Author them for real

Create the two folders and files in your context/ontology repo (in-app editor or git, per your setup — Methods in the Build Your Ontology workshop), adapting the brackets to your domains. Then submit both as patches for review — persona files are role-layer context; they take the governed path, always.

Prompt

Create behaviors/[program_manager]/org_context.md and behaviors/[analyst]/org_context.md with the two persona files above, brackets adapted to our domains, and open both as patches for review — do not apply them directly.

You’ll see: Two pending patches in Reviews — the personas exist only after approval, like any role-layer change.

Two authoring rules from the field:

Write limits as behavior, not policy. “Decline and redirect to [channel]” is executable; “users should not access restricted data” is a poster.- The persona file is the contract, not the enforcement — data-level enforcement (RLS, connector scope) lives below it (Module 6.3). Author the file assuming both layers exist.

A persona is a readable, reviewable file.

4.4 · Give every persona file a routing header

Beyond the four behavior sections, open each persona file with a short routing header so future chats (and new admins) can find and use it:

Prompt

Add a routing header to the top of each persona file: (1) Search terms - the phrases this role actually uses, including synonyms; (2) Audience - who this persona serves and who reviews it; (3) Start with - links to the canonical org definitions this role uses most; (4) one line stating what this file does NOT do. For example: "Do not redefine [core metric] here - this file routes [role] questions to the canonical org definition."

Route, don’t redefine —A persona file routes a role’s questions to the one governed definition — it never copies or redefines it. The moment a metric is restated inside a persona, you have a fork waiting to disagree. Scope, voice, and vocabulary live here; truth lives at the org layer.

✅ Checkpoint

Both persona files exist with all four sections, submitted as reviewed patches
The restricted persona’s clarification menu draws only from its allowlist
Its hard-limits section declines with a redirect and without enumerating what’s hidden
The analyst persona flags ad-hoc work and never treats breadth as an access bypass
Each persona file opens with a routing header (search terms · audience · start-with links · what it does NOT do)

​4.1 · The model: behavior is files

​4.2 · Persona one: the restricted business persona

​4.3 · Persona two: the analyst

​4.4 · Author them for real

​4.4 · Give every persona file a routing header

​✅ Checkpoint

4.1 · The model: behavior is files

4.2 · Persona one: the restricted business persona

4.3 · Persona two: the analyst

4.4 · Author them for real

4.4 · Give every persona file a routing header

✅ Checkpoint