7.1 · Persona files are governed artifacts
Everything the Ontology Operations workshop establishes for ontology files applies tobehaviors/ verbatim: version control (in-app history or git sync), changes via reviewed patches, attributable diffs, revertibility. Operational specifics for personas:
- Reviewers: persona changes touching scope (section 1, section 4) should be reviewed by the domain’s data owner, not just the context owner — widening an allowlist is an access decision wearing a markdown costume.- The regression suite: Module 5.4’s three probes (broad question / off-scope request / newly-allowed request) re-run after every persona patch. Five minutes; catches the typo that silently deleted a hard limit.- Render the behavior, not just the diff: for material changes, run the same-question test before approving — the diff shows what changed; the probe shows what it means.
7.2 · New persona, or extend an existing one?
The boundary rule: one persona per team, use case, or compliance boundary.| Situation | Call |
|---|---|
| A second team needs the same scope but different tone | Extend — tone tweaks within one file beat a near-duplicate |
| A team needs one more surface | Extend — a reviewed allowlist line (Module 5.3) |
| A different compliance boundary (data they may see that others may not, or vice versa) | New persona — never stretch one file across two compliance regimes |
| A genuinely different job (“executives want briefings, not analysis”) | New persona — different contract, different file |
| Someone wants a personal variant of a team persona | Neither — that’s personal-context territory (Module 2), or it’s a sign the team persona needs a review |
except for [person]... clauses. Personas describe roles; exceptions describe people; people-shaped exceptions belong in the personal layer or in a provisioning change.
7.3 · Audit: who changed what
The questions an auditor (or an incident) will ask, and where the answers live:| Question | Where |
|---|---|
| Who changed this persona, when, and what exactly changed? | The file’s version history / patch record |
| Who approved widening the allowlist? | The patch’s review trail |
| Who holds this persona right now? | Role membership (Settings → Members, or your IdP group) |
| Who assigned them? | The audit log (role-assignment events) — Admin & Governance, Module 5 |
| What did the persona look like on [date]? | Version history at that date — this is why direct unreviewed edits are banned |
7.4 · The quarterly persona review
Thirty minutes per quarter, per persona, with the domain owner:- Membership check — does everyone holding this persona still belong? (Stale role assignments accumulate silently.)- Allowlist check — every surface still needed? Anything granted “temporarily” a year ago?- Probe run — the three-probe regression suite, live.- Friction check — what did this persona’s users ask for and get declined this quarter? Recurring legitimate declines are extension candidates (via review); recurring illegitimate ones mean the redirect text needs work.- Sprawl check — could this persona merge with a near-twin? (See the failure table.)
7.5 · The failure modes table
| Failure mode | Smell | Fix |
|---|---|---|
| Truth forked into personal context | Two people get different numbers for the same governed question | Module 2.5’s hygiene rule; hunt with a periodic “what definitions live in personal contexts?” review; move offenders to org via patch |
| Persona sprawl | Eleven personas, six near-identical; nobody knows which to assign | The boundary rule (6.2); merge in a reviewed consolidation; aim for one per genuine team/compliance boundary |
| Allowlist rot | Surfaces granted for a project that ended; nobody removed them | The quarterly allowlist check; asymmetric review (narrowing ships fast) |
| Exception accretion | except for... clauses naming individuals | Route to personal context or provisioning; personas describe roles |
| Decline without redirect | Restricted users hit walls and file tickets instead of finding the path | Section 4 discipline: every decline names where to go instead |
| Drift via direct edits | Behavior changed; no patch explains why | Direct-edit ban on behaviors/; version history makes offenders visible |
🎓 You’re done
You can route any behavior request to its layer, build personal context that persists, curate org truth through review, author personas from the four-section anatomy, prove them with the same-question test, provision them through identity fail-closed, and operate the whole stack with the governance it deserves. The one-sentence takeaway: personal is immediate, org and role are governed — and behavioral context is the semantic layer of RBAC: auditable files, not configuration drift.7.6 · The usage-driven gap review
The quarterly review catches drift; a recurring usage review catches gaps while they’re small. Mine real activity for the personas’ blind spots:Prompt
You’ll see: a standing loop where Ana drafts, named owners approve, learnings land back in the routing docs — and context gaps become tracked work items instead of buried chat history. (Same pattern as Ontology Operations Module 4.)
✅ Checkpoint
- Persona changes route through review, with domain owners on scope changes, and the probe suite runs after every patch
- You applied the new-vs-extend rule to a real pending request
- Every audit-table row has a live answer in your setup
- The quarterly review is calendared with named owners — and the failure-modes table is in your team’s runbook
- The weekly usage-driven gap review playbook exists — Ana drafts, owners approve, gaps become work items