Auto-Ontology: who approved the meaning of active?

A dashboard asks for active customers. The database has accounts, invoices and login events, and each team uses a different definition of "active". A valid SQL query can still count the wrong population. NVIDIA's Auto-Ontology puts those definitions into a layer people can inspect before an agent uses them.

This November 4 diary is a documentation and source-code review. I have not installed the service, connected a database or measured answer quality. The project deserves a careful look because its proposed review work is concrete: terms mapped to columns, SQL expressions attached to business concepts, and relationships between tables. Its README's claim of fewer wrong answers remains a project claim, not a result established here.

What the ontology contains

The official repository describes a service beside the source databases. Ingestion extracts schemas, profiles columns and samples values. It proposes terms, table relationships and SQL attributes, then stores that context in Postgres with pgvector embeddings for retrieval. The sampling step matters to a privacy review: metadata ingestion can involve actual values, so "we only added a semantic layer" does not establish that business data stayed inside its original boundary.

A term might connect "invoice line" to physical columns and include synonyms. An SQL attribute can hold the expression for a measure such as margin. Relationships describe joins, including bridge tables. These definitions can reduce repeated invention when a question arrives. They still need review by someone who knows whether cancelled invoices belong in the total and which date means the reporting period.

The documented workflow generates a draft, lets people refine and certify definitions, then answers questions through that layer. For an answer, the agent retrieves candidate terms and attributes, writes SQL, checks filters and the query against the database, repairs failures and executes the query. Returned SQL and steps give a reviewer something more useful than a fluent total alone. They do not prove that every business choice was right.

Answerability has two separate checks

The MCP guide distinguishes readiness from answerability. check_readiness asks whether a deployment has a compiled layer and a live connection. A catalog can survive its connection; readable glossary terms therefore do not establish that a query can run. check_answerable grades whether the semantic layer covers the question. An answerable-looking question can still depend on an incorrect definition.

ask_question runs the text-to-SQL workflow through the chat-completions API. The guide describes multiple sequential model calls and returns the answer, SQL and rows separately. Its row results are capped at 100, with row_count and truncated indicating withheld output. A reader must inspect those fields before treating the visible rows as the complete result. A truncated listing and an aggregate query answer are different things.

My proposed acceptance test starts with a tiny synthetic invoice dataset. Include a cancelled invoice, a refund and a customer with logins but no purchases. Write down two plausible definitions of "active", then ask the same question under each. Record the selected definition, generated SQL, expected count and returned count. Add a question the model cannot answer from the dataset. A useful system should expose that limitation instead of quietly choosing a definition.

Where the caller's identity is checked

The MCP service is documented as an HTTP client of the public Auto-Ontology API. The path is agent client, MCP service, Next.js public API, then backend and storage. The authentication guide says the public API resolves a browser session, an API token, an OAuth bearer issued to an MCP client, or an SSO ID token from a trusted caller.

API tokens act as their owner and use that owner's role. They do not acquire separate permissions just because the caller is a script. The guide says creating and revoking tokens requires a signed-in session; a token cannot mint its own replacement. Default token expiry is never, so a team should deliberately choose a lifetime and a revocation procedure.

The MCP guide describes per-user sign-in and opaque tokens checked through Auto-Ontology's UserInfo endpoint. A viewer should receive the viewer's permitted answers. In a proposed test, use two synthetic accounts with different access and check both successful and denied requests. Revoke a grant and retry. Keep backend services behind the deployment's intended public authorization path; this review does not establish that a raw backend exposed separately has the same protections.

A Vault switch can leave credentials in Postgres

The connection guide is explicit: Vault is off by default. It requires VAULT_ADDR, VAULT_NAMESPACE, VAULT_ROLE_ID and VAULT_SECRET_ID. Partial configuration is ignored with a warning and falls back to plaintext storage in Postgres.

The Vault module checks that all four exist. The connection service writes connection JSON to the catalog row when Vault is not configured, and keeps it off that row when it is. Supplying one environment variable is therefore a poor acceptance criterion. Verify the effective storage mode using synthetic credentials and inspect backups as well as the live database. Do not paste real secrets into a diagnostic report.

A minimal review record could look like this. It is an original checklist format, not executable validation or an official Auto-Ontology schema:

{
  "fixture": "synthetic-invoices-v1",
  "question": "How many active customers?",
  "definition_reviewed": false,
  "expected_count": null,
  "sql_reviewed": false,
  "permission_denial_checked": false,
  "credential_storage_verified": false
}

Those false values are intentional. A check becomes true only when evidence exists. Keeping the expected answer outside the model's own response avoids grading the system against an answer it just invented.

What I would try first

The repository's Apache-2.0 license allows reuse under its terms. Its inspected default-branch checkout includes a November 3 commit updating model defaults. That is evidence of recent maintenance, not evidence of production suitability or a launch today.

I would begin with one business measure and a read-only sample database. Review the sampling destinations and model configuration, certify the definition, then test a denied request and a revoked grant. Keep an SQL diff when the definition changes. A deployment earns broader access only after those checks and the credential-storage check pass. The result worth keeping is a definition another reviewer can explain, with a query they can reproduce.