The semantic training gap is the difference between knowing the words of a trade and knowing how one company uses them. An AI model has read enough to talk fluently about machines and failure codes. It does not know that in your database the bonding station is called "S4". So it may invent a plausible code such as "BOND-1", find no data, and report that there are no problems.
Where does the term come from?
Grama Chethan of Siemens Digital Industries Software introduced it in a paper on AI agents in manufacturing (May 2026). He describes a disconnect between how AI systems learn a domain's vocabulary in training and how a factory gives that vocabulary meaning: through the relations between its equipment, process parameters, failure codes and regulations. His opening example is one temperature sensor with three names: TT-4201 for the process engineer, %IW64 in the PLC program and ReflowZone4 in the manufacturing execution system. An AI agent knows the jargon of all three systems, but not that the three names refer to one sensor. Its answer is "linguistically precise and operationally wrong". The author stresses that training alone cannot close that gap.
What goes wrong in practice?
On an analytics platform in development, whose twelve tools took free-text parameters, the agent was asked for non-conformance trends at the bonding station. It wrote a fluent analysis, but its database query asked for station "BOND-1". No such station exists; the bonding station is S4. The query returned nothing, and the agent reported that no failures were recorded, while that station had the line's highest rate of non-conformance reports that week.
The paper calls this tool-parameter fabrication and distinguishes it from factual hallucination: a made-up fact can be checked, but a made-up query parameter silently returns wrong data. With several agents and no shared definitions, the paper also sees semantic drift: one agent writes "S1", another "CNC-Bay-1", and their answers diverge.
How does the paper close the gap?
It puts the factory's ontology, a description of its stations, products, failure codes and certifications and how they relate, into the tool layer as a typed configuration file per domain. The tools run on an MCP server, and an orchestration layer enforces a contract of three operations:
- Resolve: every identifier in a tool call must match an entry in the loaded ontology before the query runs. If it does not, the call is rejected with the list of valid values.
- Contextualize: a valid identifier brings its context, such as the failure codes and regulations that apply.
- Annotate: every result carries that context and the ontology version.
When the agent called get_station_performance("BOND-1"), the call was rejected with the valid set S1 to S6, and the agent corrected itself to S4.
What did the experiment show?
The test used 72 questions, one per tool for each of six industry configurations, on simulated factory data, with the model Qwen3-32B at temperature 0. With free-text parameters, 31 of the 72 tool calls (43%) used a made-up identifier, and only 14 (19%) gave the correct result. With parameters limited to values from the ontology, none was made up and all 72 were correct.
What are the limits?
The paper names them itself:
- The baseline is weak. The approach was compared with no constraints at all. According to the author, a plain list of allowed values in function calling would likely remove most of the 43% on its own. RAG, few-shot prompting and fine-tuning were not tested.
- The 43% applies to one model and should not be generalised. The 0% follows from the check itself, so it holds for any model that respects such a list.
- All results come from a simulation whose six configurations the author's team wrote. In an existing factory, the ontology first has to be found before it can be enforced.
- The author works at Siemens, and the paper is a preprint.
The post on AI agent loops compares it with two other projects that move such checks into code.