Module 0 · Two Enforcement Homes

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.

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

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) — 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

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

Prompt

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.

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).

✅ 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

​0.1 · The doctrine in one line

​0.2 · The behavioral trap

​0.3 · The decision table

​✅ Checkpoint

0.1 · The doctrine in one line

0.2 · The behavioral trap

0.3 · The decision table

✅ Checkpoint