Your ontology is documentation until something enforces it
The AI industry has converged on a diagnosis: agents hallucinate about your business because they don't know your world. And on a prescription: give them an ontology — a formal map of what exists (patients, orders, visits), what identifies each thing, and how things relate. Palantir built a platform around this idea. Snowflake, dbt, and Salesforce formed a standards body for it (OSI). The knowledge-graph community has said it for a decade.
The prescription is right. But there's a gap between an ontology that informs and one that governs. Today, every one of these systems hands the map to the model as context — and hopes. Nothing checks the SQL that comes back against the map it was given. An ontology nobody enforces is documentation.
We build the enforcement half. Here's what happened when we pointed it at two real ontologies.
OSI: the spec's own examples, enforced
OSI — the Open Semantic Interchange, the vendor-neutral semantic-model format from the Snowflake/dbt/Salesforce initiative — declares exactly the facts a checker needs: what identifies an entity, and each relationship's multiplicity. Our loader reads both published spec shapes (the ontology style and the core-metadata style, including their TPC-DS example, where relationship cardinality is inferred from the declared keys). Against the spec's own example files, queries that violate the declared semantics — a count inflated by a one-to-many join, a join on an undeclared key — are rejected with fix hints; clean equivalents pass. Honest scope: this is demonstrated on the spec's published examples, not yet on production exports — if you have a real OSI file from an implementing platform, we want to run it.
OMOP: the clinical ontology, and a bug class that matters
OMOP CDM is the ontology-shaped schema that hundreds of hospitals and research networks standardize clinical data on. Its structure is public and machine-readable: every primary key and foreign key is published as a spec CSV. Feeding that spec to sqlsure produces a rulebook with 39 tables, 94 join edges, and 53 flagged sensitive columns — zero human authoring — plus a thin layer of clinical semantics the spec implies but SQL can't see: costs and drug quantities are summable; lab values are not.
What it catches, on query shapes clinical researchers actually write:
✗ COUNT(person_id) after joining person to visit_occurrence
counts VISITS, not patients — the cohort inflates with every
hospital visit. Fix: COUNT(DISTINCT person_id).
(the corrected query passes)
✗ SUM(measurement.value_as_number)
summing blood-pressure readings is never a valid statistic.
Hard error: value_as_number is non-additive.
✗ SELECT person_source_value ...
the column that links de-identified research data back to a
human — policy violation before the query runs.None of this required a semantic layer, a data team, or a config file. The ontology already said it all. It just needed something that listens. (Runnable: integrations/omop_loader.py.)
The general point
Every ontology system today — Foundry's object and link types, OSI's YAML, OMOP's spec, OWL's cardinality restrictions — declares the same three facts sqlsure enforces: identity (what one row means), relationship shape (what a join multiplies), and value semantics (what you may aggregate). The declarations exist. The queries ignore them freely. The fix is not a bigger map or a smarter model — it's a deterministic check at the moment of execution, reading declarations that already exist. We've now demonstrated the same pattern across dbt tests, MetricFlow semantic models, WrenAI MDL, OSI, live database catalogs, and the largest clinical ontology in the world.
Ontology-grounded agents are the right idea. Grounding needs teeth.
sqlsure is open source (Apache-2.0) — a deterministic semantic gate for SQL with a CLI, an MCP server, an Agent Skill, and receipts for every claim.
pip install sqlsure