A model can write perfectly valid SQL and still return the wrong yield: definitions live in code and in people's heads, so two agents produce two self-consistent numbers. A semantic layer turns business terms, column mappings and calculation logic into certified, traceable assets, so an agent first checks whether a question is answerable and under which definition. Using NVIDIA's open-source Auto Ontology as a reference, this article explains certified definitions, provenance, read-only MCP access, and why manufacturing needs this layer most.
One-line overview
The most common failure of AI analytics in manufacturing is not broken SQL - it is definitions nobody aligned. Ask for yield, run two valid queries, get two different numbers. A semantic layer turns what a metric means, which columns it maps to, which formula computes it and who approved it into certified, traceable assets. An agent then checks whether a question is answerable and under which definition before it queries anything. This is not another AI feature; it is the business foundation AI has been missing.
1. The SQL is right, the number is wrong
Take an ordinary question: what was line 3's yield last month?
- Agent A computes first-pass yield over all station records and returns 82.4%.
- Agent B computes final-inspection yield and returns 91.7%.
- Both SQL statements are syntactically valid, join correctly, and return results. Neither hallucinated.
The problem is that business meaning was never stored. Yield is a human word; the database has columns like judge, station_no and lot_id. Which value counts as passing, whether the denominator excludes debug pieces, and whether lines are merged live in engineers' heads. A model can only guess from column names and sampled values, and cannot tell when it guessed wrong.
That is more dangerous than a syntax error: the output is clean, the chart is tidy, and two departments quietly make different decisions.
2. Databases do not store business meaning
A database guarantees values and transactions, not semantics. It knows a column is an integer; it does not know whether that column represents first-pass or final-inspection yield. It knows a foreign key exists; it does not know whether that join is allowed by the business.
Pasting a schema into a model's context therefore hits three walls:
- Tacit knowledge: the mapping from column names to concepts lives in people's heads.
- Context budget: more tables consume more tokens, diluting the definitions that matter.
- Improvised joins: the model re-derives join paths on every question, with no way to validate the business logic.
Even subtler: an unanswerable question is indistinguishable from a zero result. If no advertising-spend column exists, a model may still produce SQL that returns an empty set, and the reader assumes the answer is 0.
3. What a semantic layer actually stores
A semantic layer is neither a reporting tool nor an OWL reasoner. It is a business model above relational data. NVIDIA open-sourced Auto Ontology in November 2026; its core objects fall into three groups:
| Object | What it stores | Manufacturing example |
|---|---|---|
| Term | Business concept, description, synonyms | yield, work order, LOT, engineering step |
| ColumnAttribute | Business attribute mapped to physical columns | yield to a judgement column in production records |
| SqlAttribute | Reusable derived expression (governed logic) | OEE = A x P x Q, Cpk, first-pass yield |
Together they define a metric: the term collapses wording to one concept, the column mapping says where the data lives, and the SqlAttribute supplies the certified formula. Retrieval may be probabilistic; definitions must be deterministic. Taking the deterministic part away from the model leaves hallucination only in intent understanding.
Tables hold columns and values; the semantic layer adds business terms, mappings and certified measures.
4. Why generated does not mean approved
The easiest misconception is that an automatically generated ontology is already trustworthy. It is the opposite.
The official flow has five stages: Discover (generate a starting ontology from metadata, or import existing semantic models) → Ground (reconcile conflicting definitions across systems) → Validate (check queries against certified definitions and lineage; return provenance) → Expose (MCP / CLI / API) → Learn (fold certified corrections and usage back into the ontology).
Compilation is done by an LLM proposing terms, column assignments and candidate SQL attributes - but the output is a draft. Domain experts test it with real questions, correct it, and mark it certified; uncertified content should not back an external answer. There is no shortcut: letting a model decide which denominator defines yield is handing governance to a probability distribution.
Compilation produces a draft; human certification makes a definition authoritative, and corrections flow back.
Two supporting design choices matter just as much:
- Provenance: the answer returns with the SQL, matched terms and certification status, so a number traces back to its definition.
- Read-only MCP: the official
docs/mcp.mdlists nine read-only tools (ask_question,check_answerable,check_readiness,search_terms,get_term,get_term_columns,get_term_sql_attributes,get_sql_attribute,describe_table) and states that a raw schema browser is deliberately absent - agents must go through the semantic layer.check_answerablegrades whether the layer covers a question;check_readinesschecks that the ontology is compiled and the database connection is alive, preventing a healthy-looking deployment that fails every question.
5. An open reference, with honest limits
Auto Ontology is a useful sample because its boundaries are explicit: Apache-2.0, a Next.js frontend plus FastAPI backend and ingestion service over Postgres/pgvector, Nemotron models on NVIDIA NIM by default, but configured through per-role environment triplets so any OpenAI-compatible endpoint can replace them. A SQLite connector is included, which fits development databases.
It is equally important to see what it is not yet. The official CONTRIBUTING.md states that external pull requests are not accepted, and no formal Release exists. Vault is listed as an optional component, so production deployments must harden connection-credential storage themselves. The README's claim of a 90% reduction in ontology creation time is self-reported without a published baseline; evaluation is delegated to a separate benchmark repository. In short: a design blueprint and a pilot tool, not yet production infrastructure to depend on.
6. Why manufacturing needs this most
Metric drift is structural in manufacturing: the same indicator is computed at device, line and plant level; MES, quality systems and group reporting each carry an implementation; first-pass yield, final yield and rolled throughput yield are used interchangeably in conversation; and the A, P and Q components of OEE may have different formulas in different codebases.
Industrial data also demands explicit relations: a number only means something if it says which plant, when, which line, which machine, which process step and which lot it came from, and along what control logic it was aggregated. Without those relations, certifying a definition is impossible.
Two valid SQL queries for the same yield question differ only in which denominator was certified.
Tsingley's approach is one ordinary example: the ONLINE data platform consolidates OEE and CPK definitions, and a three-loop control model describes how device, line and work-order data relate, so losses can be traced back to a specific process step. The point is not a particular product - it is whether definitions can be certified and conclusions traced to their source.
7. A pragmatic order of work
- Definitions before models: list the ten most-asked metrics and write down denominator, filters, time basis and aggregation level for each.
- Certification before coverage: five certified metrics are better than fifty draft definitions an agent may cite.
- Agents only through the layer: no raw-schema browsing, permissions inherited from the signed-in user, SQL and certification status retained with every answer.
- Pilot before dependency: run ingest to compile to
ask_questionon a demo database and test real business questions before adding it to the production stack. - Keep the semantic assets in your own store: the ontology is a governance asset and should not be locked into a young framework's data model.
8. Closing: from fast answers to correct ones
For decades, industrial software assumed a human reader: dashboards, reports, filters, clicked and read by people. Once models become the first consumers of data, the core asset stops being feature count and becomes a set of machine-reasonable business definitions that humans have approved.
A semantic layer does not make a model smarter; it lets the model guess less. Definitions are deterministic, provenance is inspectable, and unanswerable questions are stopped early. For manufacturing that matters more than another chat interface - because every number eventually lands on a line, a process step and a batch of material.
References
Facts about Auto Ontology are taken from the official repository's first-party files. The project is early-stage and its interfaces may change; verify against the current repository version.
[6] Official ontology-sql-eval benchmark repo — https://github.com/NVIDIA/ontology-sql-eval
