> ## 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 4 · Mirror the Warehouse

> Goal: when per-member auth isn’t available and the rules already exist in the warehouse, don’t re-derive them from meetings — translate them. Ana reads the policy definitions an… (~25 min)

**Goal:** when per-member auth isn't available and the rules already exist in the warehouse, don't re-derive them from meetings — **translate them**. Ana reads the policy definitions and drafts equivalent ontology guards as a reviewed patch.

<Note>
  **When this module applies** — Use this when a source must run on a **shared service account** (no per-member support, or an embedded surface) but the warehouse team has already encoded who-sees-what in row access policies, secure views, or row filters. If per-member auth is available, use Module 1 instead — a live identity beats the best copy.
</Note>

## 4.1 · Read what already exists

```text Prompt theme={null}
Inventory the access rules already defined in [warehouse] for the tables behind [source]: row access policies and their definitions, secure/authorized views and their DDL, row filters and column masks, and which roles they apply to. (Snowflake: SHOW ROW ACCESS POLICIES, GET_DDL, POLICY_REFERENCES; Databricks: information_schema row-filter and column-mask metadata, SHOW GRANTS.) List each rule as: object → rule logic → roles affected. Flag anything you don't have metadata privileges to read.
```

<Check>
  **You'll see:** the warehouse's actual policy inventory — or an explicit list of what the connector's role can't read. **If the inventory comes back empty-handed, stop:** ask the DBA to grant metadata visibility or export the policy DDL. Translating from memory defeats the purpose.
</Check>

## 4.2 · Translate into guards

```text Prompt theme={null}
For each policy in the inventory, draft the equivalent ontology enforcement: a fail-closed governed .tql guard that reproduces the same row filter keyed to the same attribute, and the persona/scope mapping that mirrors the warehouse roles. Note every place the translation is NOT exact (functions the warehouse evaluates that we can't, session context we don't have). Propose the whole set as one reviewed patch — do not apply anything silently.
```

<Check>
  **You'll see:** a patch proposing guard-per-policy, with an honest "translation gaps" list. The gaps are the review agenda — your DBA approves the mapping the way they'd approve a firewall change, because that's what it is.
</Check>

## 4.3 · The copy will drift — alarm it

A translated policy is a snapshot; the warehouse remains the source of truth. The DBA will change a policy and nobody will remember the mirror. Don't rely on memory:

```text Prompt theme={null}
Create a feed agent "Policy Drift Watch" that runs weekly: re-read the row access policies, secure view DDL, and row filters for [source] and compare against the versions recorded when our ontology guards were created. Post ONLY when a definition changed, naming the policy, what changed, and which ontology guard mirrors it. Silent otherwise.
```

<Check>
  **You'll see:** an exception-only watcher. A warehouse policy change now triggers a review of the mirrored guard instead of a silent divergence — the same drift discipline as account hierarchies and golden datasets ([**Data Quality**](/workshops/data-quality/overview)).
</Check>

### ✅ Checkpoint

* [ ] The warehouse policy inventory exists — read from metadata, not reconstructed from memory
* [ ] Each policy has a mirrored guard proposed as a reviewed patch, with translation gaps listed
* [ ] The DBA reviewed the mapping
* [ ] Policy Drift Watch is running and silent on normal weeks