Auto-Ontology: NVIDIA semantic layer that checks its answers

Summary

Auto-Ontology is an open-source semantic layer from NVIDIA: a business glossary grows out of your database, and each answer carries its SQL and steps.

Recommend
Name
Auto-Ontology
Version
0.1
Pricing
Free
Open source
Open source
Operating system
LinuxWeb
Updated
2026-11-10 23:00

Auto-Ontology is an open-source semantic layer from NVIDIA. It grows a glossary of business terms out of an existing database, then makes an agent answer questions against that glossary. The problem it goes after is the usual failure in self-service analytics: the model reads revenue as the wrong column, the SQL runs, and the number is wrong. Teams that want natural language over business data and do not trust the model's output can look at how this project turns that step into something checkable. The code is under Apache 2.0, the front end is a web interface, the back end runs in containers, and one model endpoint is enough to start.

The answer, its SQL and the chart arrive in a single reply
The answer, its SQL and the chart arrive in a single reply

What question answering lacks is a dictionary

Turning natural language into SQL has been technically possible for years. Meaning is the hard part. Customer count means accounts that placed an order, in the orders table, and companies that were registered, in the customer table. Revenue may include tax or exclude it, may be invoiced or still receivable. The model does not know which definition your company works with, so it picks a column that looks reasonable.

Auto-Ontology fills that context in first: where the data lives, what it is called, whether it may be used, how it should be used, where it came from, and which things resemble it. That knowledge usually sits in data dictionaries, SQL scripts and the heads of long-serving staff. The project collects it into a structure that can be queried, and hands that structure to the agent.

Three kinds of entry sit in the dictionary

Terms are the business concepts, customer or invoice line, each carrying a description and synonyms and mapped to concrete columns. SQL attributes hang below a term as expressions someone has reviewed, gross margin for instance, so the agent reuses one calculation instead of inventing a second. Relations record how tables join, bridge tables included, inferred from keys and from the shape of the data.

Generation runs in four steps. The ingestion service reads the source database, extracts the schema, and profiles columns and sample values. It then pulls terms table by table and maps them to columns, infers the joins between tables, and suggests SQL attributes from historical queries. The last step writes terms, relations and attributes into Postgres and stores the vectors in pgvector for retrieval.

From reading the source to writing the ontology, the ingestion service does this part
From reading the source to writing the ontology, the ingestion service does this part

What you see afterwards is a semantic graph you can click through. The official sample runs against Microsoft's Wide World Importers sales database: one compile produces 31 terms, and selecting orders lists the description, the related terms, the mapped columns and 2 SQL attributes. The numbers are small, and they show the shape of the structure.

One compile produces this graph, and any term opens onto its columns and attributes
One compile produces this graph, and any term opens onto its columns and attributes

The machine drafts, a person signs

Generated material cannot be used as it stands. Certification is its own step. You try real questions in the chat, or call the checking tools over MCP, and where a description is wrong or an attribute computes the wrong thing you edit it in the interface and certify term by term. Only certified names, descriptions and formulas count as trusted definitions in later answers.

That sounds slow, and it is the point. A semantic layer is worth something not because it generates quickly but because a person stands behind each definition. The certification flag is where that responsibility is recorded.

Answering takes one extra check

A question passes five stages: read the intent and pull out the entities it mentions, retrieve candidate terms, columns and attributes by vector search, write the SQL, test the filter values and the whole query against the database and repair what fails, then execute and return the answer together with the SQL and the steps.

The fourth stage is where it separates from ordinary text-to-SQL tools. Many write the query and run it, and a wrong or empty result goes out anyway. This one first checks whether a filter value such as Pennsylvania exists in the database and is spelled the way the data spells it, and it dry-runs the query before showing anything.

There is also a refusal path. In the official sample, a question about advertising return for a product in June 2015 has nothing behind it: coverage comes out at 0.5, and instead of inventing a figure the system replies that this data holds no ad spend and offers that month's revenue, or another database. That answer is worth more than a precise-looking wrong number.

Plugging into an agent over MCP

The project ships a FastMCP server that exposes read-only tools: check whether a deployment is ready, search terms, fetch the columns and SQL attributes of a term, judge whether a question can be answered from the current ontology, and ask a question to get an answer back with data rows. Every call runs with the permissions of the logged-in user, so it is not a master key.

It also speaks Apache Ossie, a standard for exchanging semantic models, and imports and exports YAML. An existing semantic model does not have to be thrown away, which matters to teams already running warehouse governance.

The cost, and the fit

This is not a tool you install and forget. Deployment goes through Docker Compose or Helm, needs a Postgres 17 instance, and has to reach an NVIDIA model endpoint, hosted or self-run, because both inference and embeddings go through it. The default configuration ships with a model already set, and changing it means editing environment variables.

The fit is narrow and clear: many databases, inconsistent definitions, and business users who want to ask their own questions. Connect one or two core databases, compile the ontology, certify a few dozen terms by hand, then open it to agents; the path works. The misfit is just as clear: a small team with one database and self-explanatory column names will spend more on upkeep than it gains.

What makes Auto-Ontology worth attention is not that it turns a question into SQL. It is that the project admits the model does not know your company's definitions, so it builds those definitions into a layer a person can review and a machine can query. Whether a number is right still ends with a human nod, and the work here is giving that nod somewhere to land.
Auto-OntologyDownload
Supported systems: Linux Web