Newsletter
AI

My AI diary: NVIDIA Auto Ontology tackles AI’s data trust problem

Photo: Markus Winkler on Unsplash
In this article 10 sections
  1. What’s happening?
  2. Why connecting an AI to a database isn’t enough
  3. Enter the knowledge graph
  4. A practical example
  5. What makes this different from ordinary RAG?
  6. Why this matters for AI agents
  7. The limitations are just as interesting
  8. What about the business opportunity?
  9. My take: Maybe the next AI breakthrough isn’t another model
  10. Sources

November 7, 2026 · AI / Open Source / Enterprise Technology

I was browsing GitHub’s trending projects when something from NVIDIA caught my attention. Not another massive language model. Not a new chatbot promising to replace half the office. Instead, a project called Auto Ontology was climbing the charts.

And the more I read about it, the more interesting the underlying problem became.

We’ve spent years making AI models smarter. They can write code, summarize documents, reason through complex questions, and connect to external tools. Yet give one of these systems access to a company’s database and ask a seemingly simple question about revenue, and things can get complicated surprisingly quickly.

What exactly counts as revenue? Which table contains the correct figures? Are refunds included? And what happens when two departments use different definitions for the same metric?

That’s the problem NVIDIA is trying to address.

What’s happening?

NVIDIA’s Auto Ontology is an open-source framework designed to give AI agents a more structured understanding of enterprise data.

The project is available on GitHub under the Apache 2.0 license, and its repository has attracted substantial developer attention. At the time of this research, GitHub’s trending page showed more than 2,000 stars gained during its displayed daily window.

But popularity isn’t the interesting part.

The interesting part is that Auto Ontology attempts to solve a weakness that becomes more serious as businesses give AI systems greater responsibility: knowing what the underlying data actually means.

A language model can generate convincing SQL. That doesn’t mean it understands a company’s accounting definitions or operational relationships.

NVIDIA’s approach is to build a semantic layer between the AI agent and the underlying data.

Why connecting an AI to a database isn’t enough

Imagine a business running its operations across several systems.

One database contains customer orders. Another stores invoices. A third records refunds, and a fourth contains product information.

Now imagine asking an AI assistant:

“Which product categories generated the highest net revenue last quarter?”

A conventional text-to-SQL system might inspect the database schema and generate a query. With a little luck, it identifies the correct tables and joins.

But what if the revenue column contains gross sales? What if returns are stored elsewhere? What if some transactions are recorded in different currencies?

The SQL might execute perfectly while producing a misleading answer.

That distinction matters.

A technically valid query is not necessarily a financially correct query.

And for companies hoping to use AI in financial reporting, operational analytics, or management decisions, that difference is enormous.

The problem isn’t simply that the model needs more information. It needs trustworthy definitions, relationships, and rules for interpreting that information.

Enter the knowledge graph

Auto Ontology builds what NVIDIA describes as an ontology: a structured representation of business concepts and their relationships.

Think of it as a map that connects database structures to the language people actually use.

A customer is not just a row in a table. An order is not merely a collection of columns. Revenue is not simply whichever field happens to contain the word “revenue.”

Instead, the system can associate business terms with underlying database attributes, define relationships, and preserve reviewed SQL expressions for calculations.

According to the project’s documentation, the framework works through three broad stages.

First, it generates an initial ontology by examining data sources, schemas, columns, and relationships.

Second, people review and certify definitions. This is an important detail: the system doesn’t assume that every automatically generated interpretation is correct.

Third, AI agents use the resulting semantic information when answering questions.

The architecture combines familiar technologies, including Python, FastAPI, PostgreSQL, pgvector, and a Next.js frontend.

It also exposes functionality through APIs, a command-line interface, and the Model Context Protocol, or MCP.

That makes the project relevant beyond NVIDIA’s own ecosystem.

The goal is not simply to create another interface for querying databases. It’s to give different AI tools access to a shared understanding of what those databases represent.

A practical example

Let’s imagine a fictional online retailer with three tables:

  • orders: order IDs, customer IDs, dates, and gross amounts
  • refunds: refund IDs, order IDs, and refund amounts
  • products: product IDs, categories, and descriptions

A user asks an AI agent:

“What was our net revenue last month?”

Without a reliable semantic definition, the agent might calculate the sum of gross order amounts.

But suppose the company’s certified definition is:

Net revenue = gross sales minus refunds.

A semantic layer can preserve that business rule and associate it with the appropriate data sources.

The agent can then construct a query based on the approved definition instead of improvising its own interpretation.

That’s the appeal of Auto Ontology.

The same principle could apply to customer churn, recurring revenue, profit margins, inventory turnover, or operational performance.

Of course, this is a conceptual example, not a benchmark or a test of NVIDIA’s software. Real accounting rules can be much more complicated, involving taxes, cancellations, recognition periods, currencies, and adjustments.

Still, the example illustrates why business context matters.

What makes this different from ordinary RAG?

Retrieval-augmented generation, or RAG, has become one of the most common ways to connect language models to external information.

A typical RAG system searches documents or other content, retrieves relevant passages, and includes them in the model’s context.

That’s useful for answering questions about policies, manuals, or research material.

Structured enterprise data presents a different challenge.

Finding a relevant table description isn’t enough when the answer requires joins, filters, calculations, and consistent definitions.

Auto Ontology combines semantic retrieval with a structured model of business entities, relationships, and reviewed SQL attributes.

The project’s documentation also describes query validation and answerability checks.

That last capability caught my attention.

An AI system should sometimes be able to say that it cannot answer a question from the available information.

For example, a database containing sales figures cannot necessarily answer a question about return on advertising spend if advertising costs aren’t recorded anywhere.

Recognizing that missing information is more useful than confidently inventing a result.

It also highlights an important difference between generating plausible text and delivering dependable business intelligence.

Why this matters for AI agents

The broader AI industry is moving toward systems that do more than answer isolated questions.

Agents can coordinate tools, access databases, execute code, and automate workflows. Some are designed to operate across multiple applications with limited human intervention.

That creates an uncomfortable reality.

The more autonomy we give an agent, the more consequential its misunderstandings become.

An incorrect answer in a casual conversation might be annoying. An incorrect financial metric in an automated management report could influence a real business decision.

A shared semantic layer could help address this problem by giving multiple agents consistent definitions and traceable data relationships.

Consider an organization with separate AI assistants for sales, finance, and operations.

If every assistant independently interprets the same business data, inconsistencies are almost inevitable.

If they rely on a common set of certified definitions, there’s at least a foundation for consistency.

That doesn’t eliminate errors, but it changes the architecture of the problem.

Instead of expecting every model to rediscover the company’s business logic, developers can make that logic explicit.

The limitations are just as interesting

There are several reasons not to treat Auto Ontology as a magic solution.

First, automatically discovering relationships doesn’t guarantee that those relationships are correct.

Database schemas are often messy. Legacy systems contain undocumented assumptions, and even experienced employees can disagree about definitions.

Human certification remains essential.

Second, maintaining a semantic layer introduces operational work.

Definitions change. New systems appear. Business rules evolve. A certified calculation can become outdated if nobody maintains it.

Third, the framework has real infrastructure requirements.

The documented architecture includes multiple services, a database, an ingestion component, and model integrations. This is not necessarily the kind of project someone installs in five minutes on an old laptop.

Fourth, there are security considerations.

Connecting AI agents to enterprise databases requires careful attention to permissions, credentials, sensitive information, and query execution.

The presence of authentication and access-control features does not automatically establish that a particular deployment is secure.

Finally, there’s the question of measurable performance.

NVIDIA provides documentation and an evaluation reference, but I haven’t independently tested the project or reproduced its results.

Before relying on it in production, I would want to see how it performs against difficult, unfamiliar databases and whether its validation process consistently catches semantic mistakes.

What about the business opportunity?

There’s also a broader industry angle worth considering.

The AI market has spent enormous amounts of money on model training, GPUs, and inference infrastructure.

But deploying AI inside established businesses requires more than computational power.

Companies need systems that connect models to real information while preserving accuracy, access controls, and accountability.

That creates opportunities across data infrastructure, governance, observability, and enterprise software.

For NVIDIA, projects like Auto Ontology are interesting because they demonstrate how the company can participate in the software layer surrounding AI deployment, not just the hardware underneath it.

However, an open-source repository gaining popularity doesn’t establish commercial adoption, future revenue, or investment returns.

Those are separate questions requiring separate evidence.

The relevant signal here is architectural: making enterprise information understandable and usable by AI agents is becoming an important engineering problem.

My take: Maybe the next AI breakthrough isn’t another model

What I find interesting about Auto Ontology is how unglamorous its central idea sounds.

Business definitions. Database relationships. Verified calculations. Human review.

None of those concepts makes for the kind of dramatic demonstration that usually dominates AI announcements.

But perhaps that’s exactly why they’re worth watching.

We’ve reached a point where an AI model can produce remarkably sophisticated answers while still misunderstanding something as basic as how a company calculates revenue.

Making the model larger won’t necessarily fix that.

A more reliable approach may involve giving the model better tools, clearer definitions, and stronger boundaries around what it can claim to know.

Auto Ontology is one attempt to build that foundation.

Whether it becomes widely adopted remains uncertain. Its actual effectiveness needs independent evaluation, and organizations will still have to do the difficult work of maintaining trustworthy data.

But the direction makes sense.

If AI agents are going to become useful coworkers rather than impressive demonstrations, they need more than intelligence.

They need context they can trust.

And that might turn out to be one of the most important infrastructure challenges in enterprise AI.


Sources

Editorial note: This article is based on publicly available documentation and repository information. No independent installation, benchmark reproduction, or hands-on evaluation was performed.

This is my personal opinion, not investment advice. I am not a licensed financial adviser. Do your own research. Disclaimer

Get Thomas' briefing by email

One short email on days with a new article. Nothing on the other days.

More on AI