> ## 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 7 · Operate the Stack

> Goal: the operating habits — versioning and review of persona files, when to add vs extend a persona, audit, the quarterly review, and the failure modes to watch for. (~15 minutes)

**Goal:** the operating habits — versioning and review of persona files, when to add vs extend a persona, audit, the quarterly review, and the failure modes to watch for.

## 7.1 · Persona files are governed artifacts

Everything the [**Ontology Operations**](/workshops/ontology-operations/overview) workshop establishes for ontology files applies to `behaviors/` 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.**

<table><tr><th>Situation</th><th>Call</th></tr><tr><td>A second team needs the same scope but different tone</td><td>Extend — tone tweaks within one file beat a near-duplicate</td></tr><tr><td>A team needs one more surface</td><td>Extend — a reviewed allowlist line (Module 5.3)</td></tr><tr><td>A different *compliance boundary* (data they may see that others may not, or vice versa)</td><td>**New persona** — never stretch one file across two compliance regimes</td></tr><tr><td>A genuinely different job ("executives want briefings, not analysis")</td><td>New persona — different contract, different file</td></tr><tr><td>Someone wants a personal variant of a team persona</td><td>**Neither** — that's personal-context territory (Module 2), or it's a sign the team persona needs a review</td></tr></table>

The smell to watch: a persona file accumulating `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:

<table><tr><th>Question</th><th>Where</th></tr><tr><td>Who changed this persona, when, and what exactly changed?</td><td>The file's version history / patch record</td></tr><tr><td>Who approved widening the allowlist?</td><td>The patch's review trail</td></tr><tr><td>Who *holds* this persona right now?</td><td>Role membership (Settings → Members, or your IdP group)</td></tr><tr><td>Who assigned them?</td><td>The audit log (role-assignment events) — Admin & Governance, Module 5</td></tr><tr><td>What did the persona look like on \[date]?</td><td>Version history at that date — this is why direct unreviewed edits are banned</td></tr></table>

If any row has no answer in your setup, that's the gap to close this week.

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

<table><tr><th>Failure mode</th><th>Smell</th><th>Fix</th></tr><tr><td>**Truth forked into personal context**</td><td>Two people get different numbers for the same governed question</td><td>Module 2.5's hygiene rule; hunt with a periodic "what definitions live in personal contexts?" review; move offenders to org via patch</td></tr><tr><td>**Persona sprawl**</td><td>Eleven personas, six near-identical; nobody knows which to assign</td><td>The boundary rule (6.2); merge in a reviewed consolidation; aim for one per genuine team/compliance boundary</td></tr><tr><td>**Allowlist rot**</td><td>Surfaces granted for a project that ended; nobody removed them</td><td>The quarterly allowlist check; asymmetric review (narrowing ships fast)</td></tr><tr><td>**Exception accretion**</td><td>`except for...` clauses naming individuals</td><td>Route to personal context or provisioning; personas describe roles</td></tr><tr><td>**Decline without redirect**</td><td>Restricted users hit walls and file tickets instead of finding the path</td><td>Section 4 discipline: every decline names where to go instead</td></tr><tr><td>**Drift via direct edits**</td><td>Behavior changed; no patch explains why</td><td>Direct-edit ban on `behaviors/`; version history makes offenders visible</td></tr></table>

## 🎓 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:

```text Prompt theme={null}
Create a playbook "Weekly Context Gap Review" that runs Monday mornings: review the last 14 days of usage - repeated questions, mid-thread corrections, failed context lookups, and questions users rephrased until they worked. Group them by business concept, flag concepts hit by multiple users or roles, and propose small reviewable patches: a persona-file addition, an org glossary entry, or a routing-README update. Draft the patches for review - do not apply them - and list unresolved gaps as work items with suggested owners.
```

<Check>
  **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](/workshops/ontology-operations/overview) Module 4.)
</Check>

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