A neutral ontology layer keeps the enterprise’s approved business meaning independent of any one application, warehouse, or agent platform. Atlan’s Context Layer for AI supports this approach by connecting those definitions to their authoritative sources, owners, lineage, and approval rules, making the same business meaning available across platforms.
How does a neutral ontology relate to ontologies and context layers?
An ontology in AI is a formal model of business concepts, their properties, and their relationships. A context layer connects that meaning to sources, owners, approval status, and operational context. A practitioner’s perspective on ontology, context, and semantic data layers makes the same distinction.
“Neutral” describes where authority sits, and the model itself stays specific to the business. It still starts with designing an ontology model that defines business terms, identifies authoritative sources, and assigns approval. The distinction here is to build an ontology-first AI architecture without making business definitions from a single platform an authoritative source for internal tools, AI systems, and agents.
Two related ideas sit next to neutrality. An active ontology stays current as the systems it describes change, and an operational ontology connects business meaning to governed actions. Neutrality is a separate property: it decides who controls the approved version.
To better understand surrounding boundaries, it is helpful to review key comparisons, such as ontology vs. semantic layer, context graph vs. ontology, and ontology vs. knowledge graph.
For companies building a neutral ontology layer, the defining questions come down to who controls the approved meaning and whether every relevant platform and agent can use it. In most enterprises, those questions expose how fragmented that meaning has already become.
From Ontology to Context Layer: What Actually Changed With AI?
Source: Atlan on YouTube
Your ontology is already fragmented
Ontology fragmentation usually happens by accident. Warehouses, BI tools, business applications, and agent platforms let teams define concepts where they already work. This feels natural and frictionless in the beginning. But over months and years, it produces conflicting definitions of critical business terms such as customer, product, order, and revenue, with no agreement on which version other systems should use.
Consider net revenue. Finance changes the approved BI calculation to exclude pending refunds. A warehouse agent still runs the older SQL definition, and a support agent applies its own refund rules. Each answer makes sense locally, yet leadership receives three numbers for the same question.
Context silos across AI teams turn into disagreement at scale. Context drift begins when a definition changes in one system but not in its copies. Agent sprawl multiplies the impact as those definitions flow into reports, recommendations, and automated actions.
Enterprise Knowledge observed in 2026 that independently developed ontologies can become isolated assets requiring mapping or redesign. Teams must then reconcile definitions and maintain additional mappings.
A 2026 IETF Internet-Draft describes a related problem at the protocol level: when agents express capabilities, task intents, and context semantics in incompatible vocabularies, the mismatch “blocks cross-domain discovery, reliable task decomposition, and predictable coordination.” It is an individual draft with no formal standing in the IETF standards process, but it discusses how inconsistent meaning becomes an operational problem.
Resolving fragmentation does not require erasing every domain model. The enterprise can connect these systems of semantics through shared concepts and authority. A semantic layer standardizes metric and calculation logic; the context layer connects it to lineage, ownership, policies, quality, and usage; and an enterprise data graph maps assets and relationships. Together, they expose the origin, ownership, and use of shared meaning. Without that foundation, local definitions become a recurring cost.
What does a platform-bound ontology cost you?
A platform-native ontology can ground its own agents well. Problems arise when its definitions must guide the entire enterprise: teams synchronize copies, reconstruct meaning as technology changes, and investigate conflicting outputs. This adds maintenance work and decision risk.
These costs appear in three recurring forms:
- Drift between copies: Definitions do not change together. Finance may update “active customer” in a BI model while warehouse and support agents keep older versions.
- Rework during change: Changing a warehouse or agent framework can force teams to rebuild and retest entities, relationships, and business rules in the new tool’s format. Changing a model more often means retesting prompts and tools against the same definitions.
- Conflicting agent outputs: Agents using different platform definitions may interpret the same customer, product, or metric differently. A correction in one platform does not reach the others on its own.
Platform semantics have become much more open, and a fair comparison starts there. Metric and semantic-view definitions can live as YAML in Git and ship through CI. Apache Ossie (incubating), previously the Open Semantic Interchange, defines a vendor-neutral format for business metrics, dimensions, and their relationships. At least one warehouse can already create a semantic view from Ossie YAML and export one back, in preview, per its OSI guide. Some platform ontologies export to Turtle or RDF/XML, also in preview, though a successful import doesn’t guarantee every source construct survives. And some platforms serve their semantic models to outside agents through a managed MCP server.
Export solves the copy problem for one platform’s model. It leaves three questions open: which platform’s version wins when two disagree, who approves a change that affects several domains at once, and where concepts that are not metrics, such as entitlement or risk, get defined and mapped. If each platform still authors, approves, and versions its own copy, the enterprise has portable files but no shared authority.
Context portability asks whether context can move across the technology stack. Single-stack dependence and platform-native context layers present broader versions of the problem. For the ontology, the test is whether the enterprise can maintain, approve, and serve definitions when its technology changes.
Related guidance covers how to extend a warehouse ontology across the enterprise, how to make a platform ontology a local consumer, or how to pair it with a neutral context layer. A model-agnostic context layer and multi-cloud context layer extend that principle across models and infrastructure.
What does neutral actually mean?
In a neutral ontology layer, “neutral” means the enterprise controls its approved business definitions and can make them available across engines, models, agents, and platforms as its technology changes.
This matters in an environment where enterprises use several models. According to Andreessen Horowitz (2025), 37% of 100 surveyed CIOs used five or more models, up from 29% the previous year. Model count alone does not split meaning, because several models can sit behind one governed retrieval path. The risk grows when each new model arrives with its own agent framework, tool descriptions, or prompt-embedded definitions. If the approved definitions depend on a single platform, every one of those consumers needs either access to that platform or a copy of the definitions to maintain.
Four tests make neutral concrete:
| Test | What it means | Evidence to look for |
|---|---|---|
| Enterprise ownership | Accountable business owners control approval, versioning, and conflict resolution | Named owners, approval records, change history, and the ability to maintain the approved version independently |
| Open representation | Definitions remain readable and transferable outside the tool in which they were created | Documented formats, stable identifiers, explicit mappings, and usable exports |
| Multi-engine access | More than one compatible engine can query or use the approved definitions | Standard interfaces and successful tests with the engines the enterprise uses |
| Multi-model and multi-agent delivery | Different models and agent frameworks receive the same approved definitions | Open delivery interfaces, identity-aware access, and definition-version references in agent traces |
Open formats and open protocols solve different parts of the portability problem. The W3C OWL 2 overview describes a language for expressing formally defined ontology meaning that can be exchanged as RDF documents. Apache Iceberg is an open table format that multiple engines can use to store tabular data or supporting context, but it does not represent ontology semantics by itself. OWL can express formal mappings between terms, and Apache Ossie gives metrics and dimensions a shared exchange format. None of these formats determines who owns a definition or who approves it.
The Model Context Protocol specification standardizes how language-model applications connect to external data and tools. That explains how MCP can deliver business context and why MCP matters for AI agents, but the protocol does not decide which definition is authoritative.
MCP standardizes the connection. Ownership of the meaning is settled somewhere else. An open context endpoint can serve an approved ontology to any compatible agent. Putting the same kind of endpoint in front of a platform-owned ontology still leaves that platform in control of the definitions. When an enterprise runs several LLM providers, serving one pinned, approved version removes one source of disagreement. Consistent answers still depend on governed execution, aligned data, and access policy.
Together, these tests turn questions about who will own AI context and who owns the context layer into a practical ownership test: can the enterprise approve, maintain, represent, and deliver its business meaning independently as its technology changes?
Context is IP: why ownership is the real question
Treat the ontology like source code the enterprise owns. It needs accountable maintainers, version history, testing, review, and a controlled release process. Changing the meaning of critical business terms such as customer, revenue, risk, or entitlement can affect every AI agent decision that depends on them.
Atlan supports enterprise ownership of the ontology through four connected capabilities in its enterprise context layer. Each capability addresses a different part of building, maintaining, and distributing approved business meaning.
Context Agents bootstrap the ontology from definitions and signals already present in enterprise systems, including SQL, lineage, BI logic, and usage patterns. Sage finds where two teams define the same metric differently, routes the conflict to the relevant stewards, and updates the definition once they approve one. Orion maps the relationships between domains, terms, and assets. Lower-confidence proposals route to stewards, who decide what the business means.
The Enterprise Data Graph connects definitions to assets and relationships across the enterprise. Column-level lineage shows which tables, dashboards, and downstream assets depend on a governed definition, so teams can see the impact of a change before they release it. Definitions that live only in an agent’s prompt have no lineage edge, which is one reason to move them into the governed layer.
Context Engineering Studio gives domain teams a workflow to test, review, approve, and release business meaning. Approved definitions and relationships can be packaged in Context Repos as versioned, portable units of context. A repository references the governed assets it is built from instead of copying them. When a source changes, teams regenerate the repository and review the result, so a change reaches agents only after someone accepts it.
This is also how approved meaning reaches platform-native agents. Context Engineering Studio stores each repository in an engine-agnostic format and renders it into the semantic object each deployment target expects, such as a warehouse semantic view or a lakehouse metric view. Redeploying replaces the live object in place. Agents that read the repository over MCP get the same definition without a deploy.
Context Lakehouse applies the principles of a lakehouse built for AI to the storage and delivery of context. It is Iceberg-native and serves context through MCP, A2A, SQL, and APIs. Iceberg is only the storage format; the meaning lives in the approved definitions and relationships. Different agents and platforms can then read the same approved definitions without each team authoring its own copy.
Together, these capabilities give the enterprise a repeatable context engineering approach for building, maintaining, and distributing trusted context as its systems change. Agents across warehouses, BI tools, and business applications can use the same approved meaning, while domain owners approve what changes.
Run the four neutrality tests on any layer you evaluate, Atlan included: where the authoritative artifact lives, what format you can export it in, which engines consume it without the vendor, and what you keep if you leave. Atlan is a launch partner of the Open Semantic Interchange, the specification now developed as Apache Ossie.
Real stories from real customers: context that spans the estate
Enterprise data leaders describe the cross-estate role in practical terms. Sridher Arumugham, Chief Data Analytics Officer at DigiKey, says:
“Atlan is our context operating system to cover every type of context in every system including our operational systems.”
Joe DosSantos, VP, Enterprise Data and Analytics at Workday, describes how shared business language reaches AI:
“Atlan captures Workday’s shared language to be leveraged by AI via its MCP server. As part of Atlan’s AI labs, we’re co-building the semantic layer that AI needs.”
"AI initiatives require more context than ever. Atlan's metadata lakehouse is configurable, intuitive, and able to scale to hundreds of millions of assets. As we're doing this, we're making life easier for data scientists and speeding up innovation."
Andrew Reiskind, Chief Data Officer, Mastercard
"Context is the differentiator. Atlan gave our teams the shared vocabulary and lineage to move from reactive data management to proactive AI enablement."
Kiran Panja, Managing Director, Cloud and Data Engineering, CME Group
Does a neutral ontology layer mean replacing your existing platforms?
No. Warehouses, BI tools, and business applications keep their data, their compute, and the business logic they execute. When a platform has its own ontology or semantic model, it keeps grounding local agents, and, where the platform is a supported deployment target, the neutral layer publishes the approved shared definitions into that model’s native format. The platform stays the place where queries run. The neutral layer becomes the place where shared meaning is approved.
This turns the choice between a full-stack platform and a best-of-breed context layer into a clear division of responsibilities. Platforms handle their specialized functions, while the neutral layer maintains shared meaning across them. It also feeds the cost of building, buying, or bundling a context layer: count the recurring work spent reconciling copied definitions, and weigh it against the cost of running one more layer.
FAQs about neutral ontology layers
1. What is a neutral ontology layer in one sentence?
A neutral ontology layer is enterprise-owned infrastructure that maintains approved business definitions and makes them usable across platforms, models, and AI agents.
2. What makes an ontology neutral or vendor-agnostic?
A neutral ontology combines enterprise ownership, open representation, multi-engine access, and delivery across models and agents. Export to an open format and an API both help, but neither is enough if one platform still decides how shared definitions are approved and which version wins when platforms disagree.
3. Who should own the enterprise ontology: the data team, the AI team, or the platform?
The enterprise should own it through a shared operating model. Domain leaders approve business meaning, data and architecture teams maintain its technical structure, and AI teams report gaps found during use. Ownership can be scoped: finance and sales can each hold a valid definition of revenue, as long as each is bounded to its domain and agents know which one applies.
4. What goes wrong when each platform keeps its own ontology?
Definitions drift because updates made in one platform do not automatically reach the others. Teams must then reconcile conflicting outputs and rebuild business meaning whenever their technology changes.
5. My platform already has an ontology. Why add a neutral one?
Add one when the same concept has to mean the same thing in more than one platform. A single-platform estate with one semantic model may not need it. Once two platforms each hold a version of customer or revenue, someone has to approve the shared version and publish it to both. The guide to extending an ontology beyond one warehouse walks through that pattern for a single platform.
6. If my platform exports its semantic model and serves it over MCP, is that ontology neutral?
It is portable, which is half of it. Export lets you move one platform’s model, and MCP lets outside agents read it. Neutrality also needs the approval and conflict-resolution step to sit with the enterprise rather than inside one platform’s object model. For the broader lock-in question across models and clouds, see single-stack lock-in versus a neutral context layer.
7. What open formats can an ontology live in?
It depends on what is being modeled. Formal ontologies use OWL, which is primarily exchanged as RDF in syntaxes such as RDF/XML or Turtle; JSON-LD can also carry RDF. Metrics, dimensions, and their relationships have their own open exchange format in Apache Ossie. Many teams need both: OWL for concepts and constraints, Ossie for the calculations that BI tools and agents run. Storage formats such as Iceberg hold the files and say nothing about their meaning.
Sources
- How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025
- How to Scale a Semantic Layer with Interoperable Ontologies
- Ontology, Context and Semantic Data Layers
- Ontology-based Semantic Interaction for Internet of Agents
- Model Context Protocol specification
- Apache Ossie (incubating)
- Apache Iceberg
- OWL 2 Web Ontology Language Overview
