Enterprise AI and the semantic core: Building an OS for knowledge

For two decades, enterprise transformation has followed a familiar sequence: digitize, automate, optimize. Each phase built upon the last. Digitization gave us data. Automation let software do what people used to. Optimization layered on analytics and ML to make sense of the flood. Each wave built on the last, but none of them solved a deeper problem.

No shared meaning

Now, as generative AI rolls out, the gap is harder to ignore: most enterprise systems have no shared understanding of what anything means. Data is plentiful and models are capable, yet the result is fragmented reasoning, inconsistent outputs and AI that behaves like a brilliant intern who understands every word but not the job or the mission.

Today the urgency is sharper than ever. LLMs are already inside critical systems, but they’re running without guardrails. They hallucinate. They contradict themselves. They produce outputs no one can trace or defend in an audit. The EU AI Act and NIST’s AI RMF are pushing organizations toward provable consistency and auditability. As organizations deploy multiple models and emerging AI agents, semantic fragmentation grows – making a shared ontology layer not optional, but foundational.

What’s missing is a semantic core – the conceptual backbone that unifies an organization’s knowledge across systems, models and missions. It’s not another database or platform. It’s the layer where data becomes meaning, and where meaning becomes computable.

From tangled wires to a unified circuit

The ‘data silo problem’ never disappeared; it changed form. Even with APIs, systems define core entities differently. A ‘customer’ may mean an active subscription in one application and a ‘prospect’ in another.

When AI models train on systems that define the same term differently, the outputs look coherent but aren’t. One system’s ‘incident’ is another’s ‘exercise.’ The model doesn’t know that; it just pattern-matches across both and produces confident nonsense.

Formal ontologies solve this by making meaning explicit. They specify what things exist in a domain, how they relate and what rules constrain them. When definitions conflict, you can see it. Instead of inferring structure from column names or schema, an ontology encodes it explicitly. This transforms the enterprise’s information environment from a collection of syntactic databases into a coherent map of meaning.

Why AI needs a semantic core

Many enterprise AI failures are data-and-assumptions problems, not computational. Large language models can generate grammatically flawless text and detect statistical correlations, yet they lack grounding in what those correlations represent. When enterprises deploy such systems across high-stakes workflows, including financial analysis, supply-chain forecasting and threat detection, they risk decisions that sound convincing but collapse under scrutiny.

A semantic core addresses this gap by grounding AI in the logic of the enterprise. If you formally define what ‘incident’ means versus ‘exercise,’ or ‘person’ versus ‘organization,’ models can reason within those boundaries instead of guessing from raw text. The ontology stops being a reference document and starts acting as infrastructure.

Building semantics as infrastructure

Building a semantic core begins with structured domain modeling aligned with a top-level ontology. The process identifies the entities, relationships and processes that define how the organization operates. The resulting model becomes the reference for aligning data and supporting consistent AI reasoning across systems.

Enterprises should build on existing, standards-based ontologies rather than creating their own. ISO/IEC 21838-2 standardizes a top-level ontology, which provides a stable, interoperable upper framework for domain modeling.

Once the ontology is in place, the next step is to bring real data into it. Operational systems feed records into the knowledge graph, where a row in a table becomes a specific thing in the world – a customer, an asset, an incident. Columns turn into attributes of that thing, and links between records become explicit relationships.

The same happens for unstructured material. Documents, images, logs and other files are attached to the entities they describe, so everything is connected instead of floating in separate systems. Each item gets a stable identifier and a small set of standard tags so it can be recognized and reused anywhere in the graph.

Before any of this data is accepted, it runs through validation rules that ask simple but important questions: does this reference a real object in a system of record, is the value in the right format, are we using an approved term? Those checks keep the graph internally consistent and give downstream models a single, reliable view of how everything fits together.

Under the hood, this uses web standards like Internationalized Resource Identifier (IRI), Dublin Core, SKOS and SHACL but the key idea is simple: every piece of data is labeled, checked and linked so models can trust the context they’re operating in.

System-level reasoning happens in two places. First, during retrieval: the system pulls from the knowledge graph (and the vector index when relevant) to assemble the facts, relationships and rules that give the model real context to work with. Second, after the model generates something: a verifier checks the output against enterprise rules and semantic constraints. Nothing gets stored or passed downstream until it clears that check.

Typical RAG finds documents that are statistically similar to your query. Graph-backed retrieval goes further. It can follow relationships: this asset connects to that facility, which falls under these regulatory constraints, which reference that maintenance history. Once you have that structure, forecasting can account for dependencies across assets and facilities. Compliance checks can run automatically before anything moves downstream.

An operating system for knowledge

At that point, the ontology stops being documentation. It becomes infrastructure. Think of it as an operating system for knowledge: the layer that keeps data, models and reasoning aligned. Without it, AI systems drift: definitions start to diverge across teams, and policies end up existing only on paper, not in code. Models train on inconsistent inputs and learn to repeat the inconsistencies. And if the semantic layer itself is poorly designed, you’ve hard-coded misunderstandings into every downstream system. Fixing that later costs far more than getting it right up front.

AstraZeneca offers a concrete example. Its Biological Insights Knowledge Graph (BIKG) serves as a semantic core for R&D, unifying internal and public data on genes, compounds, diseases and pathways under a shared ontology. Discovery teams use the graph to surface drug target candidates – for instance, identifying the top targets to pursue for a given disease. Separately, AstraZeneca researchers have demonstrated that reinforcement learning-based multi-hop reasoning on biomedical knowledge graphs can generate transparent explanation paths showing which targets, pathways and prior evidence support each suggestion, outperforming baselines by over 20% in benchmarks.

Semantic maturity is a CIO problem

This isn’t a technical footnote. It’s strategic. AI readiness used to mean data volume and GPU capacity. Now it means semantic maturity: having a consistent, machine-readable model of what your organization knows, how things relate and where the reasoning comes from. Without that, AI projects stay brittle. They demo well and fall apart in production.

A semantic core maps directly onto what CIOs already care about: interoperability, governance, trust. But building it requires pulling together people who don’t usually collaborate, including data architects, compliance leads, systems engineers, domain experts. It becomes the shared language of enterprise intelligence, one that both humans and machines can interpret.

The ROI is concrete. Integration gets cheaper because new systems plug into a common framework instead of bespoke point-to-point connectors. Search stops matching keywords and starts retrieving actual knowledge. Model retraining speeds up because the underlying data stays semantically consistent.

In regulated industries, this approach strengthens traceability and auditability. It won’t magically explain what’s happening inside the model. But because the entities, relationships and rules are explicit, you can trace outputs back through data lineage and policy constraints. Pair the knowledge graph with provenance standards like W3C PROV, and you get verifiable decision trails. That’s compliance-ready evidence, even when the model itself remains a black box.

Beyond systems of record

Enterprises have spent decades building systems of record for transactions, systems of engagement for interactions, systems of insight for analytics. Each layer added capability. None of them solved the meaning problem. The next step is building systems of understanding, architectures that unify those layers through shared meaning.

When systems share a semantic fabric, alignment happens at the data level. A maintenance log references the specific asset it describes. A financial transaction links to its counterparty and regulatory category. Information stops flowing through disconnected pipes and starts forming a coherent network.

Systems interpret data the same way. New sources plug in without massive rewiring. Reasoning can operate across the whole environment because the parameters are shared.

Siemens has documented multiple Industrial Knowledge Graph use cases where semantic models integrate data from plants, parts, sensors and service reports into a single knowledge layer. The approach supports applications across business areas and has been carried beyond initial feasibility projects. Siemens notes that a formal semantic representation enables inference, cross-source integration and schema-on-read for extensions instead of complex schema migrations.

Laying the groundwork

The journey toward a semantic core does not begin with massive restructuring. It starts with clarity. Pick one domain, one product line, one process area. Model it, integrate it with existing pipelines and extend from there. Governance matters from the beginning. The ontology should be treated like any strategic asset: proposed changes get reviewed, versions get tracked, releases only go live after validation. That discipline is what prevents silent drift as systems evolve around it. Over time, the network of ontologies becomes the organization’s semantic memory. Not centralized, not static. Distributed across domains, transparent to the people who use it and refined continuously as the business learns.

The main cultural challenge is to treat knowledge as a managed asset. Ontology development should be funded as infrastructure, maintained over time and integrated into enterprise architecture frameworks with the same rigor applied to networks and security.

Adopting this approach improves deployment speed and interoperability. New systems integrate more easily, and organizations gain a clearer record of how and why decisions are made.

The semantic era of enterprise AI

The next phase of digital transformation will depend less on larger models and more on how effectively organizations structure their own knowledge. Ontologies provide the framework that allows machines to reason in ways that are transparent and auditable. In an era defined by autonomous agents and multi-model ecosystems, enterprises will rise or fall on the quality of their semantic infrastructure.

Enterprises that develop a semantic core can move from pattern recognition toward grounded reasoning, producing results that align with organizational definitions and context.

The semantic core is not another layer of software. It is the connective tissue of intelligent operations, the structure through which meaning itself becomes computable. Data, models, rules, processes: without shared meaning underneath them, they’re just artifacts running in parallel. With it, they become a system that can reason. Cloud changed how we provision infrastructure. DevOps changed how we ship code. Semantics changes something more fundamental: whether machines can understand what they’re operating on.

Organizations that invest now in semantic modeling and governance will shape the practical definition of enterprise intelligence in the years ahead.

They will not just have data. They will have understanding. And understanding is the ultimate competitive advantage.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?