# NVIDIA Auto Ontology NVIDIA Auto Ontology (`NVIDIA/auto-ontology` on GitHub, Apache 2.0) is an open library that builds a business [[Ontology|ontology]] from the metadata of a company's databases, so [[AI Agents]] can answer plain-language questions against that data. NVIDIA says it "builds that layer from enterprise metadata, reconciles definitions across systems", and serves it over [[Model Context Protocol (MCP)|MCP]], a CLI and a REST API. It's meant to sit next to the semantic models a company already has, not replace them. Why should you care? Because the hard part of asking an LLM to query your data isn't the SQL. Models write decent SQL. The hard part is knowing what the columns *mean*. One HN commenter called it the "semantic gap": a timestamp column that could be UTC or local time, an amount stored in cents that only the application code converts, a customer count that should exclude test accounts. None of that is in the schema. It's [[Tribal Knowledge]]. ## What the ontology contains 1. **Terms**: business concepts with a description, synonyms and the columns they map to 2. **SQL attributes**: reviewed SQL expressions (a margin, a rolling total) 3. **Relationships**: how tables join, bridge tables included It's stored in [[PostgreSQL]] with pgvector embeddings, and can be imported and exported as Apache Ossie YAML. ## How it works Three phases: 1. **Generate.** Read the sources, profile the columns, extract and map terms, infer relationships, suggest SQL attributes, write the ontology 2. **Certify.** People test it with real questions, fix the definitions and certify them 3. **Answer.** Classify the intent, retrieve candidate definitions by embedding search, write the SQL, check the filters and the query (repairing what fails), run it, and return the answer with the SQL and the steps it took Certified corrections flow back into the ontology. And the agent only answers what the ontology covers: in the README's example, it says outright that a question about ad spend can't be answered from the sample data. I like that (a refusal beats a confident wrong number). Some details: - **Sources**: PostgreSQL, MySQL, Databricks, Snowflake, ClickHouse, Trino, Apache Kyuubi, HeavyDB, [[DuckDB]] and [[SQLite]] - **Models**: four roles (reasoning, non-reasoning, embedding, reranking). The defaults are [[NVIDIA Nemotron]] 3.5 models behind an NVIDIA API key, but any OpenAI-compatible endpoint works, including self-hosted NIMs. Use models that support structured output, and keep the same embedding model for ingestion and queries - **Predictions**: optional KumoRFM integration for predictive questions. It uploads the connected tables to a hosted service, so read what it sends before turning it on - **Stack**: Next.js frontend, FastAPI and [[LangChain]] backend, a separate ingestion service, a FastMCP server. The MCP tools are read-only (`check_answerable`, `ask_question`) - **Security**: keep ports 3001 and 3002 on a private network. The API trusts a forwarded user header and the ingestion endpoints have no authentication - **Contributions**: not accepted for now; issues are welcome ## What Hacker News said The launch thread (290 points, 139 comments, November 2026) argued about four things: - **The README.** Many readers couldn't tell what the tool does. One called it "unmotivated slop", another pasted it into an LLM to get a readable summary (the irony wasn't lost on anyone). A commenter's own description of the pipeline ended up clearer than the docs - **Reliability.** "Fixing unreliable agents by adding more unreliable agents" was the skeptic's line. The best answer: the ontology is built once and corrected over time, so each query runs against "the _same_ converted thing", which cuts the variation per question - **Novelty.** OWL, RDF and SPARQL have existed for decades. Fair, though one commenter argued that LLMs handle SQL better than SPARQL, and Postgres has better engines - **Governance.** The comment I keep coming back to: building an ontology forces a company to write down rules like "exclude test accounts whenever you count customers" and to settle conflicting definitions of "revenue". "Every analyst on the team does it without thinking, it's rarely written anywhere." Another put the job change plainly: data engineers stop answering one-off queries and start reviewing the ontology ## My take The AI part is the least interesting part. The Certify step is where the value is. The tool makes an organization do what it should have done years ago: decide what "active customer" or "revenue" means, write it down once, and have a person sign off on it. That's [[Enterprise Knowledge Management (EKM)]] applied to data, and a [[Single Source of Truth (SSOT)]] for business definitions. It's also the reason I keep typed notes in my own vault: declared types replace guesses. An agent querying a database without that layer guesses, and a guess that runs as SQL comes back as a precise-looking wrong number. The skeptics are right that ontologies are old. What changed is the cost of the first draft. Before, someone had to model the whole domain by hand, and few companies paid for it. Now a model drafts it from metadata and people review it. Reviewing is much cheaper than writing from scratch. Keep in mind that the ontology is now documentation, with the same failure mode as all documentation. If nobody owns it, it drifts away from the data, and the agent answers with last year's definitions. I'd budget for that owner before I'd budget for the GPUs. ## References - Repository and README: https://github.com/NVIDIA/auto-ontology - Hacker News, "Nvidia – open-source auto-ontology": https://news.ycombinator.com/item?id=50348962 ## Related - [[Ontology]] - [[Tribal Knowledge]] - [[Enterprise Knowledge Management (EKM)]] - [[Single Source of Truth (SSOT)]] - [[Knowledge Graph (KG)]] - [[Context Engineering]] - [[AI Agents]] - [[AI Hallucination]] - [[Model Context Protocol (MCP)]] - [[SQL]] - [[PostgreSQL]] - [[DuckDB]] - [[SQLite]] - [[NVIDIA Nemotron]] - [[LangChain]] - [[Apache 2.0 License]]