7.1 · Validate with golden datasets
Prompt
You’ll see: accuracy checked against known-correct outputs — and a pinned test that will alert on drift.
7.2 · Govern with access policies
Prompt
You’ll see: governance expressed in the model — fail-closed access rules, reviewable like any other file. (Module 9 takes this further with full personas.)
Make it enforceable, not advisory — Row-level rules in .tql only bind queries that go through the ontology. To make them the only path, ask your admin to mark the connection TQL-only — plain SQL is then refused on that connection in every surface, and admins can also revoke the raw-sql role permission or disable raw SQL org-wide (see Admin & Governance, Module 3.4b). The order matters: the work you just did in this workshop is the prerequisite. TQL-only removes the ungoverned path without creating a governed one — locking a connection whose ontology doesn’t yet cover users’ real questions strands them (and locking one with no query files makes it unqueryable). Build first — the modules you’ve completed — verify coverage (Ontology Operations §2.5), then lock. The full security build lives in the Row-Level Security & Identity-Aware Access workshop.
✅ Checkpoint
- At least one metric has a golden-query test pinning its expected value
- Sensitive surfaces fail closed, and you can point to the access logic in the .tql