--- service: "Publicasta" schema_version: "1.0" article_id: 1126 title: "NVIDIA Auto Ontology turns enterprise metadata into an agent context layer — what is ready to test" language: "en" default_language: "en" canonical_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=en" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=en" api_url: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=en" channel_url: "https://publicasta.com/api/public/v1/channels/open_source_radar" channel_articles: "https://publicasta.com/api/public/v1/channels/open_source_radar/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-11-04T13:52:22+00:00" updated_at: "2026-11-04T13:52:22+00:00" translations: - language: "ar" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ar" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=ar" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=ar" - language: "de" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=de" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=de" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=de" - language: "en" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=en" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=en" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=en" - language: "es" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=es" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=es" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=es" - language: "fr" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=fr" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=fr" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=pl" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=pl" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=ru" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=ru" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing?lang=zh" markdown_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.md?lang=zh" json_url: "https://publicasta.com/open_source_radar/nvidia_auto_ontology_semantic_layer_agent_data_testing.json?lang=zh" --- # NVIDIA Auto Ontology turns enterprise metadata into an agent context layer — what is ready to test > NVIDIA’s new Apache-2.0 Auto Ontology project promises more reliable agent queries by making business definitions, lineage, relationships, and provenance explicit. The practical question is whether its deployment and credential model fit a real data stack. ## What NVIDIA released and what the ontology layer is supposed to do ![Editorial visualization of enterprise metadata flowing through a semantic graph into an AI data agent.](https://publicasta.com/storage/projects/10/pages/1126/2026/11/6e65ded1-0370-47ab-a268-e5d402ff8ee0.webp) NVIDIA Auto Ontology is presented as an Apache-2.0 Python framework for turning enterprise metadata into a structured context layer for data agents. Its purpose is not to replace a language model, a database, or a conventional data catalog. Instead, it sits between those systems: it gathers information about tables, columns, business definitions, relationships, lineage, and provenance, then organizes that information so an agent can use it when interpreting a question and forming an analytical query. That distinction matters because an agent can produce syntactically valid SQL while still misunderstanding the business meaning of the request. A database may contain several versions of revenue, customer, shipment, or activity data, each with different time boundaries and ownership. A model that sees only table names and column descriptions may choose a plausible field without knowing which definition has been certified, how a metric is derived, or which upstream system is authoritative. Auto Ontology is intended to make those connections explicit rather than leaving them to the model’s inferred associations. The repository describes a framework that can generate or connect enterprise ontologies from metadata and reconcile definitions across systems. In practical terms, the ontology is a machine-readable representation of the organization’s data concepts and their relationships. It can associate a business term with physical data structures, connect related entities, preserve lineage, and retain the provenance needed to understand where a definition or relationship came from. The result is closer to a governed semantic map than to a collection of documents retrieved for a prompt. Auto Ontology also exposes this context through several interfaces. The project includes a web application, an API, a command-line interface, and an MCP integration intended for agent harnesses. Those interfaces provide different entry points into the same broader workflow: ingest metadata, construct or review the ontology, and make its semantic information available to applications that need to answer data questions. MCP is especially relevant for teams already testing tool-using agents, because it provides a way for an external agent environment to call ontology-backed capabilities instead of embedding the entire catalog and reasoning process in a prompt. The supported architecture therefore has two separate concerns. One is the enterprise data environment: the databases, schemas, metadata systems, and definitions that the project connects to or ingests. The other is the ontology and reasoning layer that interprets those inputs and presents relevant context to an agent. Keeping those concerns separate is useful operationally. An ontology layer can describe a source without becoming the source itself, and it can help an agent navigate several systems without requiring every business rule to be rediscovered from raw database structure. This is also why Auto Ontology should not be evaluated as a generic vector-search product. Semantic retrieval may be part of an implementation, but the project’s stated value depends on structured relationships and metadata, not simply on finding text that resembles a user’s question. A vector index can retrieve a definition; it does not, by itself, establish whether two metrics are equivalent, which dataset is upstream, or how a concept maps to a join path. The ontology model is meant to preserve those connections so that the agent receives context with structure and traceability. The same boundary separates the project from a model endpoint. Auto Ontology does not make an agent reliable merely by adding another generation step. Its proposed contribution is the context supplied to the model: the definitions it should respect, the entities it can relate, the lineage it can inspect, and the provenance it can use to judge confidence. The quality of the final answer still depends on the underlying model, the metadata available for ingestion, the configuration of the deployment, and the quality of the organization’s own definitions. That makes the project interesting as a testable data-engineering component rather than as a promise of automatic semantic correctness. A team can ask whether ontology-grounded context changes the agent’s behavior on a controlled set of business questions. It can inspect whether the generated query uses the certified concept, follows an appropriate relationship, and preserves the intended scope. It can also examine whether the answer remains explainable: not just which rows were returned, but why a particular dataset, definition, or lineage path was selected. The initial practical question is therefore narrower than whether Auto Ontology solves enterprise analytics. It is whether the framework can make an existing agent more aware of the organization’s data vocabulary and structure. NVIDIA’s project offers the components for that experiment—metadata ingestion, ontology construction, semantic access through an API or MCP, and interfaces for operating the system—but the proof must come from a bounded evaluation against known schemas and known answers. The ontology layer is the proposed bridge between raw enterprise metadata and agent reasoning; the next question is whether that bridge improves answers in the cases where business meaning, rather than SQL syntax alone, determines what is correct. ## The useful test: can business meaning improve agent answers The practical problem Auto Ontology is meant to address is not whether an agent can produce SQL that runs. It is whether the query represents the business question. A column called `revenue` may not carry enough information to tell an agent which definition to use; a customer table may describe accounts, billing entities, or end users. The result can be syntactically valid, numerically plausible, and semantically wrong. NVIDIA describes Auto Ontology as a way to give agents explicit context before they query, including business terms mapped to columns, reviewed SQL for measures, and relationships between tables. ([Repository README](https://github.com/NVIDIA/auto-ontology)) That context should be testable as a chain rather than accepted as a general promise. A business concept should resolve to a definition that a team can inspect and, where appropriate, certify. The definition should identify the relevant tables, columns, or metric logic; relationships should explain which joins are legitimate; lineage should show how an answer depends on upstream assets; and provenance should make the source of the metadata visible. The value is not that the agent sounds more certain. The value is that a reviewer can see why a term was selected and how it led to the generated query. “Certified” also needs to mean more than “created by an ingestion job.” A useful test should separate definitions that a domain owner has reviewed from suggestions that remain provisional. If an ontology defines “active customer” according to approved business logic, questions using that phrase should resolve to the corresponding metric or query path. If the system cannot show which definition was used, which relationships supported the join, or which source assets contributed to the answer, the semantic layer has not made the result sufficiently accountable. A bounded evaluation is more revealing than a broad demonstration. Start with a small schema containing a few fact and dimension tables, a date field, and at least one deliberately ambiguous measure. Prepare questions with known answers, including cases that require a specific join, a defined reporting period, or a distinction between similar metrics. Run each question first through a conventional text-to-SQL path with the schema and ordinary documentation, then through an ontology-grounded path. Keep the model, data, and permissions as consistent as possible so that the comparison measures the context layer rather than unrelated changes. Record more than execution success. For each run, capture the generated SQL, the concepts and relationships retrieved, the filters applied, and the final result. Review whether the query used the intended definition, preserved the correct grain, joined the right entities, and answered the question a domain expert actually asked. NVIDIA’s repository describes an answerability check and returns SQL and the agent’s steps with an answer; those artifacts should be part of the evaluation, not discarded after the interface displays a result. ([Auto Ontology README](https://github.com/NVIDIA/auto-ontology)) Negative tests are essential. Ask about an overloaded term, omit a necessary time boundary, or request a relationship the schema does not support. The desired behavior may be a clarification request or an explicit indication that the question is not answerable. A polished number is not a success if the agent silently selects a convenient table. The MCP documentation likewise exposes `check_answerable` alongside question answering, and its `ask_question` tool returns the answer, SQL, and rows as separate fields, which makes this behavior easier to inspect in an agent harness. ([MCP documentation](https://github.com/NVIDIA/auto-ontology/blob/main/docs/mcp.md)) Finally, classify failures instead of reducing the result to one accuracy figure: wrong business definition, invalid join, incorrect grain, missing filter, unsupported claim, or merely inefficient SQL. Feed reviewed corrections back into the glossary and relationships, then rerun the same known-answer set. That creates a useful feedback loop only when each metadata change is reviewable and attributable. If ontology grounding improves semantic accuracy, clarification behavior, and traceability on questions whose definitions are explicit, it has earned a place in further testing. It has not, by itself, established that arbitrary enterprise queries are reliable. ## What running it actually requires NVIDIA Auto Ontology is closer to a small data platform than to a package that can be added to an existing agent with one command. The repository describes a deployment built from several services: a frontend for the web interface, a backend that exposes the application and API surface, ingestion services that connect to enterprise data sources and build the ontology, and Postgres with pgvector for application state and vector-backed retrieval. The documented paths are Docker Compose for a local or single-host setup and Kubernetes for a more operational deployment. That division matters because the test is not only whether the ontology produces a better answer; it is whether a team can keep the services, database, model endpoints, and credentials aligned as one system. The model layer is another explicit dependency. Auto Ontology is designed to work with NVIDIA NIM endpoints or compatible model endpoints, and its configuration covers more than the language model used to interpret a question. Embedding and reranking choices also affect how metadata and candidate context are selected before an answer is produced. In practical terms, two installations using the same source schema can behave differently if they use different model, embedding, or reranking configurations. A useful evaluation therefore records those settings alongside the questions and outputs. Otherwise, a change in retrieval or model configuration can be mistaken for an improvement in the ontology itself. The database side is similarly concrete. The project is intended to connect to supported enterprise databases and use their metadata as input, while Postgres and pgvector serve the application’s own persistence and retrieval needs. That creates a boundary between the databases being described and the store used by Auto Ontology. A trial should map that boundary before any credentials are entered: identify which source systems will be read, what metadata or lineage information will be collected, where the resulting ontology is stored, and which service is allowed to reach each endpoint. The architecture is manageable, but it is not a lightweight single-binary installation that can be dropped into an agent runtime without infrastructure decisions. There are two main ways to put the resulting context in front of an agent. The project exposes an API path for applications that want to call its services directly, and its MCP documentation describes an MCP server that can be used by an MCP-compatible agent harness. MCP is useful when the agent already knows how to discover and call tools, while the API is the more direct integration point for a controlled application or evaluation script. In either case, the agent is not querying a magic second database. It is invoking Auto Ontology’s semantic and retrieval capabilities so that business definitions, relationships, and related metadata can be incorporated into the request or query workflow. That distinction should shape the first test. Start with one small, non-sensitive database or representative schema, bring up the Compose deployment, and verify the frontend, backend, ingestion path, Postgres/pgvector store, and model endpoint independently before connecting an agent. Then run the same fixed questions through the API or MCP route and keep the model, embedding, reranking, and source configuration unchanged. Check not only the final prose answer, but also whether the generated SQL is valid, whether it uses the intended tables and definitions, and whether the system exposes enough provenance to explain the result. A deployment that answers one demonstration question correctly is not yet evidence that the whole integration is reliable. The operational cost is therefore part of the product question. Teams need container orchestration, a persistent Postgres service, model access, network routes to source databases, and a plan for upgrades and failures across separate components. Kubernetes may make that repeatable at organizational scale, but it also makes ownership and observability more important; Docker Compose can shorten a bounded evaluation while leaving production concerns unresolved. The sensible threshold for moving beyond a test is not that the interface works, but that the team can reproduce the setup, constrain access, identify which component produced an answer, and remove or replace the ontology service without leaving the agent or source systems in an ambiguous state. ## License, credentials, and the reasons to stay cautious Apache-2.0 makes Auto Ontology relatively easy to evaluate from a licensing perspective: teams can inspect, run, modify, and redistribute the project under the license terms. NVIDIA also publishes container artifacts and identifies third-party components separately. That is useful for a technical assessment, but it should not be confused with a complete production-support commitment. The repository says that the Auto Ontology team maintains the code and does not accept external pull requests; integration requests and bug reports are handled as issues. In practice, an adopter should assume that important fixes, release decisions, and security-sensitive changes remain dependent on the maintainer team. That ownership model matters because the project is large enough to have several operational boundaries: the web frontend and authentication layer, FastAPI backend and ingestion services, PostgreSQL with pgvector, model endpoints, database connectors, and the MCP bridge. A public issue also points to documentation that still describes the repository as NVIDIA-internal even though the repository is public. The discrepancy is not itself a vulnerability, but it is a sign that documentation should be checked against the code, deployment manifests, and released images before a team treats the quickstart as an authoritative operating procedure. The same review should confirm which image tags, Helm values, API routes, and model endpoints are approved for the intended environment. The most consequential warning is credential storage. Connections added through the UI are stored differently depending on whether HashiCorp Vault is configured. Without Vault, the full connection object, including the password, is serialized into a PostgreSQL catalog row without encryption. Vault changes that arrangement by storing the credentials separately and leaving the catalog row without them, but Vault is optional and a partial configuration falls back to plaintext storage with a warning. That makes the setting an architectural control, not a minor convenience. Before connecting a production warehouse, security teams should verify the actual Vault configuration, inspect database backups and replicas, restrict catalog access, and confirm that connection records cannot be read by roles that do not need them. The internal service boundary deserves the same level of attention. The project documentation says that ports used by the FastAPI backend and ingestion service should remain on a private network. The frontend passes the user identity to the backend, while ingestion operations such as ingest, delete, reset, and compile do not have authentication of their own. The intended path is therefore through the authenticated web application or the public API gateway, not direct exposure of those FastAPI services. Publishing the internal ports behind a load balancer, opening them to a broad cluster network, or assuming that an MCP client supplies the missing authorization would undermine the boundary on which the deployment model relies. Model and hosted-service choices add another data-governance question. The default configuration uses NVIDIA-hosted model endpoints, while self-hosted NIM or compatible endpoints can be configured by role. Predictive questions can also be routed to KumoRFM when enabled; the documentation states that connected tables may be uploaded to that hosted service, subject to its configuration limits and terms. An evaluation should therefore record where schema metadata, sampled values, prompts, generated SQL, and query results travel. “Open source” describes the Auto Ontology code and does not automatically make the configured model provider, connector, database, or hosted prediction service part of the same trust boundary. A sensible adoption path is a contained pilot with synthetic or non-sensitive data, network policies that keep internal services private, Vault enabled before UI-managed credentials are added, and model endpoints chosen deliberately. Test authentication and role behavior through the same API and MCP paths that agents will use. Keep a known-good ontology export, database access configuration, and deployment version so the team can disable compilation or roll back without losing the reference state. Then require an independent security review before production use, including checks of secrets, logs, backups, outbound traffic, dependency provenance, and permissions on every connected source. The practical conclusion is narrower than “Auto Ontology is ready” or “Auto Ontology is unsafe.” It is ready to test as a metadata and agent-context layer, provided the test treats deployment and data handling as part of the product rather than as setup details. Its Apache-2.0 license lowers the barrier to inspection, while plaintext connection storage without Vault, unauthenticated internal service endpoints, hosted-model boundaries, and maintainer-controlled changes raise questions that a demo cannot answer. The right proof is a small, reversible deployment whose security controls, query behavior, and rollback procedure are all demonstrated before the ontology is allowed to sit in front of sensitive enterprise data.