> ## 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 6 · Governance & PHI Defaults

> Layer 4 makes compliance the default, not an add-on: HIPAA minimum-necessary framing, the CMS small-cell (<11) suppression rule, and sensitive-diagnosis gating (42 CFR Part 2). … (~15 min)

Layer 4 makes compliance the default, not an add-on: HIPAA **minimum-necessary** framing, the CMS **small-cell (\<11) suppression** rule, and **sensitive-diagnosis gating** (42 CFR Part 2). The behavior lives in `ontology/notes/governance-phi.md` and `config/org_context.md` — files you can read, review, and adapt.

## 5.1 · Inventory your identifiers — day one

`governance-phi.md` §0 classifies every direct identifier in the connected schema into exactly one role — and the key distinction is that **using an identifier as a join key is not the same as outputting it**:

<table>
  <tr><th>Identifier</th><th>Role</th></tr>
  <tr><td>Member/subscriber/beneficiary IDs (`member_id`, `mbi`, `mrn`)</td><td>**Join key only** — never in an output column, chart, label, or log</td></tr>
  <tr><td>Names, SSN, full DOB, phone, email, address</td><td>**Never output** (DOB may be used internally for age math; only age/age-band leaves)</td></tr>
  <tr><td>ZIP code</td><td>**Aggregate only** — first 3 digits max, and only where the area > 20,000 people</td></tr>
  <tr><td>Surrogate keys (`person_id`)</td><td>Join key; output only in explicitly authorized member-level views — a stable pseudonym is still an identifier</td></tr>
</table>

```text Prompt theme={null}
Inventory every direct identifier in the connected schema and classify each per governance-phi.md section 0: join-key-only, never-output, or aggregate-only. Flag anything ambiguous for compliance review.
```

<Check>
  **You'll see:** a per-column classification your compliance team signs off on — the rules are templates tuned to *your* regime, and they can be tightened freely but never loosened without a reviewed, attributable decision.
</Check>

<Warning>
  **Facilitators: pre-flight these tests** —

  Run 5.2 and 5.3 yourself **before** any session with compliance in the room. These guardrails are **instruction-layer enforcement** — they live in the governance context files Ana reads, which makes them verifiable and tightenable, but they depend on those files being attached and current. If a test doesn't fire: check that the ontology repo (with `governance-phi.md` and `config/org_context.md`) is connected to the thread, and that your fork didn't drift from the governance defaults. Demonstrating the *check* is part of the story — "here's the file, here's the behavior, here's how we audit it."
</Warning>

## 5.2 · Test the small-cell rule

```text Prompt theme={null}
Break down [a rare condition] prevalence by county. Apply our suppression rules and tell me what you suppressed and why.
```

<Check>
  **You'll see:** cells under `min_cell_size` suppressed with an explanation — including complementary cells that would let someone back out a suppressed value. The starter default is **11** (the CMS standard), configured in `config/org_context.md`; common alternatives are 10 (some state agencies) or 30 (some internal policies). *If suppression doesn't fire, don't move on — work the pre-flight check above; an unenforced rule you catch is a better demo than a rule you assumed.*
</Check>

## 5.3 · Test sensitive-diagnosis gating

```text Prompt theme={null}
Show me member-level detail for [a 42 CFR Part 2-protected category].
```

<Check>
  **You'll see:** Ana decline or constrain the request per the gating rules — and point to the policy file that governs it.
</Check>

### ✅ Checkpoint

* [ ] Small-cell suppression fired and was explained
* [ ] A sensitive-category request was gated, with the governing file cited