Skip to main content
Goal: ontology-enforced boundaries made bypass-proof, with the operating habits that keep them true.

​
6.1 · The three dials, in the right order

Where the ontology is the enforcement layer (Modules 3–4), plain SQL on the same connection is a bypass. Close it with the admin-side dials — per-connection TQL-only, the per-role raw-sql permission, the org-wide switch (Admin & Governance Module 3.4b has the full framework). The sequencing rule from that workshop applies doubly here: the governed surfaces you built in Modules 3–4 are the prerequisite — build first, verify coverage, then lock. Where the warehouse is the enforcement layer (Module 1), raw SQL is already constrained by the user’s identity — locking is optional narrowing, not a requirement.

​
6.2 · Audit both ledgers

  • Warehouse audit log — per-member queries under real identities; your compliance system of record.
  • TextQL audit log — every execution’s provenance (raw_sql vs governed_tql) and every blocked attempt with its reason. Filter raw-SQL hits against sensitive connections: each is a gap to close or evidence the dials work (Admin & Governance Module 5.1).

​
6.3 · Operate it

  • RLS-bearing .tql files get a designated security reviewer — changes to row filters are firewall changes (Ontology Operations §2.5 has the review routing).
  • Policy Drift Watch (Module 4.3) stays on for every mirrored source.
  • Re-run the Module 5 suite after every policy change and platform upgrade.

​
✅ Checkpoint

  • Ontology-enforced connections are TQL-only — flipped only after coverage was verified
  • You know which ledger answers which audit question
  • A security reviewer owns RLS-bearing files; drift watch and the test suite are scheduled