> ## 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 0 · Two Enforcement Homes

> Goal: know exactly where each access rule should live before writing any of them. (~15 min)

**Goal:** know exactly where each access rule should live before writing any of them.

## 0.1 · The doctrine in one line

**The warehouse decides what data an identity may retrieve. TextQL decides which resources that identity may use. The ontology makes the authorized analysis accurate and consistent.**

<table><tr><th>Layer</th><th>Enforces</th><th>Role</th></tr>
<tr><td>**Warehouse identity + policies**</td><td>Permitted rows, columns, objects, grain</td><td>Compliance boundary — the hard floor</td></tr>
<tr><td>**TextQL platform (roles, connector scope, query-path dials)**</td><td>Which connectors, surfaces, and query paths a member may use</td><td>Resource authorization</td></tr>
<tr><td>**Ontology (.tql guards, governed surfaces)**</td><td>Canonical definitions + *optional narrowing* beyond the floor</td><td>Semantics and defaults; the enforcement layer itself when the warehouse can't be</td></tr></table>

When enforcement lives at the warehouse, access holds *no matter how a query is produced* — governed TQL and ad-hoc SQL both run under the user's identity. When enforcement lives in the ontology, it only binds queries that go through the ontology — which is why Module 6's **TQL-only** lock exists.

## 0.2 · The behavioral trap

A persona file that says "you may only use the East-region surfaces" is an instruction to Ana, not a control. Ana follows it; a determined user with SQL access doesn't have to. Behavioral scope is real and useful (see [**The Context Stack**](/workshops/context-stack/overview)) — but nothing in this workshop is done until the boundary holds against a user actively trying to cross it (Module 5).

## 0.3 · The decision table

<table><tr><th>Scenario</th><th>Warehouse enforcement</th><th>Ontology scoping</th><th>Raw SQL</th></tr>
<tr><td>PHI/PII, external vendors, tenant isolation</td><td>**Required**</td><td>Optional narrowing</td><td>Only under a restricted warehouse identity</td></tr>
<tr><td>Internal analysts with entitlements (region / line of business)</td><td>**Required**</td><td>Recommended — defaults + semantics</td><td>Enabled (their identity constrains it)</td></tr>
<tr><td>Executive aggregate-only access</td><td>Required (secure aggregate view)</td><td>Recommended</td><td>Only against permitted aggregates</td></tr>
<tr><td>Customer-facing embedded workflow</td><td>Strongly preferred</td><td>Governed API surface with runtime scope</td><td>**Disabled** if the ontology is the only scoping</td></tr>
<tr><td>Prototype while DBA policies are being built</td><td>Planned final control</td><td>Useful temporary boundary</td><td>Disabled for scoped users</td></tr></table>

```text Prompt theme={null}
For each connection in this workspace, tell me: the credential model (shared service account vs per-member), whether the warehouse behind it has row access policies / secure views / row filters we'd know about, and which rows of a warehouse-vs-ontology enforcement decision would apply. I'm deciding where row-level security should live for each source.
```

<Check>
  **You'll see:** your sources mapped to the table above. Most organizations land on: per-member auth for the analyst warehouses (Module 1), ontology guards for embedded/API surfaces and sources without per-member support (Modules 3–4).
</Check>

### ✅ Checkpoint

* [ ] You can state the one-line doctrine and what each layer enforces
* [ ] You can explain why a persona file is not a security control
* [ ] Every connected source has a tentative enforcement home from the decision table