The Wrong Number, Delivered Faster

Every enterprise that has pointed an LLM at its warehouse has had the same moment: the agent returns a number, the number looks plausible, the SQL is syntactically immaculate, and the number is wrong. Not wrong because the model fumbled the syntax — wrong because revenue means something different in Finance than it does in Sales, or because the join the agent improvised crosses a bridge table it didn’t know existed, or because the question was never answerable from this database at all and the agent answered anyway.

This is the gap NVIDIA’s Auto-Ontology is built to fill. The project’s framing is blunt and correct: agents can already retrieve documents and query databases, but reliability is what gates agentic analytics. A revenue figure delivered faster is worth nothing if it’s wrong. Auto-Ontology is a service you run next to your databases that compiles their metadata into an ontology — business terms mapped to columns, reviewed SQL for measures, and the relationships between tables — and then serves that context to agents over MCP, agent skills, and a REST API.

It is not a model. It is not a framework for prompt engineering. It is infrastructure for the least glamorous problem in enterprise AI: making sure everyone, human and agent alike, means the same thing by the same word.

The shortcut it replaces

The default approach to giving an agent database context is to paste the schema into its context window. Auto-Ontology’s README contains a comparison table that reads like an indictment: with schema-in-context, tokens grow with every table and column; meaning is limited to column names with the agent inferring the rest; joins and measures are improvised per question; and unanswerable questions get answered confidently, often wrongly.

The alternative is not more context but tools over a curated layer. The agent queries the ontology for only the terms and tables a question touches. Meaning comes from business terms mapped to columns and SQL, not from the agent’s guess about what ext_price represents. Join paths are resolved relationships, not improvisation. And before any query runs, there’s an answerability check — if no term in the ontology covers what the question asks, the agent says so and asks for clarification instead of fabricating a plausible join.

That last part deserves more attention than it gets. The README’s example is a question about return on ad spend against a sales database with no advertising data. An agent connected through MCP runs check_answerable, gets a coverage score of 0.5 with no term covering “ad spend,” and responds by offering the revenue it can compute or asking whether ad spend lives in another source. This is the difference between an agent that fails loudly and one that fails silently — and silent failure is the failure mode that kills enterprise trust in agents permanently.

Three stages, and the boring one is the point

Auto-Ontology works in three stages: generate, certify, answer.

Generation is the part that sounds impressive. An ingestion service reads source databases — schemas, column profiles, sampled values — extracts business terms table by table, maps them to columns, infers joins and bridge tables from keys and from the data, and even suggests SQL attributes from query history. The result lands in Postgres with pgvector embeddings for retrieval, and renders as an explorable semantic graph in the web UI. One compilation of Microsoft’s Wide World Importers sample database produced 31 terms.

Certification is the part that actually matters. People test the draft with real questions, refine terms and SQL attributes in the UI or through the API, and certify names, descriptions, and measures once they’re correct. The ontology holds three kinds of definition — terms with descriptions and synonyms, reviewed SQL expressions under each term (so a margin or rolling total computes the same way every time), and relationships including bridge tables.

This is where Auto-Ontology intersects a live argument in the knowledge-graph world. Sergey Vasiliev argues that GraphRAG and similar systems remain prototypes rather than enterprise tools because they lack real CRUD support: knowledge evolves, regulations change, and a system that can’t update or delete its assertions produces outdated answers and loses credibility. Auto-Ontology’s answer is to make the update loop a first-class product surface — a UI where a named person reviews, edits, and signs off on definitions, rather than a pipeline artifact nobody owns. A commenter on Kamal Kishore Sharma’s LinkedIn analysis of the project puts it in banking terms: the hard part was never writing definitions, it was keeping them current and having a named person sign them off. Generating a first draft from metadata “saves months”; the certification loop is what makes the draft trustworthy.

Sharma’s post is worth reading alongside the README because it names the historical failure mode Auto-Ontology is attacking: ontology has been one of the most misunderstood and underinvested areas of data science, because getting teams to agree on definitions, mapping them across systems, and keeping them updated required enormous effort. The automation of the groundwork — not the definitions themselves — is the actual innovation. The definitions still need humans. The project is honest about this in a way most semantic-layer marketing is not.

Answering, and showing its work

When a question arrives, the agent classifies intent, extracts entities, retrieves candidate terms and SQL attributes by embedding search, writes SQL, checks filter values and the query against the database, repairs the SQL when a check fails, and returns the answer with its SQL and the steps it took. Every answer in the Chat UI shows the SQL, the rows, and the resolution path — which terms were resolved, which joins were followed. You can download the rows or read them as a chart.

This provenance is not a nicety. In the GraphRAG literature, Enterprise Knowledge identifies traceable reasoning paths and auditable answers as the core advantage of ontology-grounded retrieval over flat-chunk RAG. Auto-Ontology applies the same principle to structured data: an answer you can’t audit back to a certified definition is an answer you can’t defend in a board meeting.

Where it sits in the semantic layer versus knowledge graph fight

Auto-Ontology lands in the middle of an ongoing turf war. One camp, articulated by Colrows, argues semantic layers handle execution — compiling business questions into governed, deterministic SQL — while knowledge graphs handle context, and that knowledge graphs suffer ontology drift and offer no compile-time guarantee that generated SQL matches graph assertions. The other framing, from Rathnakumar Udayakumar, holds that the two are complementary: semantic layers give consistent business definitions, knowledge graphs supply relationships, and together they power governed analytics and more reliable agents.

Auto-Ontology is interesting precisely because it refuses to pick a side cleanly. It is a semantic layer in function — one definition per business concept, reviewed SQL, resolved joins, answers compiled to auditable queries. But it stores the result as a semantic graph with terms, relationships, and embeddings, which is knowledge-graph architecture wearing a semantic layer’s clothes. The Colrows piece cites benchmarks that frame the stakes: the best text-to-SQL model achieving only 31% on enterprise schemas (Spider 2.0), and the best LLM managing 61.58% on text-to-Cypher over full-scale knowledge graphs (CypherBench). Neither number is about Auto-Ontology, but both explain why the middle ground it occupies — a curated, human-certified graph that compiles to SQL — is where enterprises are increasingly looking. Vendors like Graphwise and Glean are selling variations of the same thesis: grounding AI in structured enterprise meaning is the fix for unreliable outputs.

What distinguishes NVIDIA’s entry is that it’s Apache-2.0 source you run yourself, next to your own databases, across ten engines — PostgreSQL, MySQL, Databricks, Snowflake, ClickHouse, Trino, Kyuubi, HeavyDB, DuckDB, and SQLite. And it’s interoperable with Apache Ossie, the open standard for exchanging semantic models, with a converter in the Ossie project for import and export. If you already own semantic models, Auto-Ontology is positioned as a complement, not a replacement.

The evaluation, and what it doesn’t tell you

The companion repository, auto-ontology-eval, measures the ontology’s effect on benchmarks including BIRD, BEAVER, FDABench-Lite, and Wide World Importers. The methodology is sound and unusually honest: each question is asked of the same model twice, once with the schema in the prompt (control) and once through the ontology-backed agent (treatment), scored by a deterministic verifier using execution match against each benchmark’s official rule. The report lists not just the accuracy difference but the questions the ontology fixed and the ones it broke — an admission that a curated layer can hurt as well as help, which is rarer than it should be.

What the README does not provide is the numbers themselves. No headline accuracy lift is claimed anywhere in the material available. That’s either commendable restraint or a gap, depending on how cynical you are about vendor-published benchmarks; either way, anyone evaluating the project should run the eval themselves rather than trust a summary. Community reaction on Reddit exists — threads in r/dataengineering discussing the release — but the content was inaccessible at the time of writing, so independent practitioner sentiment remains an open question.

Rough edges

The project is candid about its trust boundaries, which is refreshing, but the boundaries are real. The FastAPI backend trusts a user identity forwarded in a header from the frontend, and the ingestion service’s endpoints — ingest, delete, reset, compile — have no authentication of their own. The README’s instruction to keep ports 3001 and 3002 on a private network is not a footnote; it’s the security model.

The model configuration defaults to NVIDIA’s own endpoints on build.nvidia.com, with four roles (reasoning, non-reasoning, embed, rerank) defaulting to Nemotron models. Any OpenAI-compatible endpoint can be substituted, but the gravitational pull toward NVIDIA’s catalog is obvious, and the runtime disclaimer is explicit that the software interacts with external model endpoints under each provider’s terms.

The predictions feature carries the sharpest caveat: enabling KumoRFM means the agent uploads your connected tables to a hosted service, capped at twenty tables by default. The README tells you to review what that sends and complete your organization’s data review before enabling it. For a product whose entire pitch is governed, on-premises-adjacent context, routing predictive questions through a SaaS upload is a tension the project acknowledges rather than resolves.

And the governance of the project itself is worth noting: the Auto-Ontology team maintains the code and does not accept external pull requests. Integration requests and bug reports are welcome as issues. That’s a common corporate-open-source posture, but it means “open source” here means source-available with community input routed through a queue — relevant if you were hoping to fork the certification workflow into something your data governance team already runs.

The NGC catalog shows a 1.2.0 release updated November 6, 2026, with signed containers at around 305 MB — signs of an actively maintained, production-intended artifact rather than a research drop.

Outlook

The open question is whether ontology maintenance can stay cheap enough to keep the certification loop alive. Auto-Ontology automates the draft; humans still have to review it, and the moment that review backlog grows faster than the automation, the project reverts to the classic failure mode — a stale ontology that’s worse than no ontology, because everyone trusts it. The CRUD critique from the GraphRAG world applies here too: the README describes editing and certifying, but says little about versioning definitions over time or tracing an agent’s answer back to the specific definition version it used, which Sharma’s LinkedIn commenter identifies as the real evolution needed.

The bigger bet, as Sharma notes, is a connected enterprise ontology spanning scattered databases and domains — one definition of customer across the warehouse, the lakehouse, and the operational store. Auto-Ontology’s multi-engine connectors and Ossie interoperability point in that direction. Whether it gets there depends on the same thing that has always decided ontology projects: not the generation, not the graph, but whether someone’s name is attached to each definition and whether that person still answers their email.