For most of the history of enterprise software, business meaning didn't need to be fully explicit, because a human was always positioned to catch the gap. An analyst who found two conflicting numbers for "active customers" would ask around, find out which definition applied to their report and move on. The data didn't need to carry its own meaning, because a person supplied the interpretation it lacked.

AI systems remove that person. When someone asks an AI assistant a direct question, the assistant answers directly. There's no analyst standing between the question and the response to catch an ambiguous definition or flag a stale source. That changes what goes wrong when business context isn't explicit: conflicting definitions get resolved silently, in whatever direction the AI system happens to guess. Answers come back fluent and confident regardless of whether they're right. There's no way to tell after the fact which source should have been used. And there's no audit trail explaining what a term meant at the moment an answer was generated.

Connected business context is what closes that gap, and it does more than reduce errors. It's what makes it possible to put AI in front of people who have no way to check its work themselves. A customer, a frontline employee or an executive asking a quick question isn't in a position to verify that an AI system used the right definition of "revenue." The trust has to be built into the system before the answer ever reaches them.

Here's what that difference looks like in practice. Ask an ungoverned AI system, "How many active customers did we have last quarter?" and it might query whichever table looks closest to relevant, apply an undocumented threshold for what "active" means and return a number with total confidence. That number may not match what the finance team would report. Ask the same question against a connected ontology, and the system resolves "active customer" to its one governed definition, confirms which system holds the authoritative data for that metric and returns a number it can trace back to a named source and owner. It’s the same question. But a very different level of trust in the answer.

The measurement is stark. Anthropic's June 2026 engineering post reported agents querying raw business data answered correctly less than 21% of the time. Given curated, governed context (which is what a connected ontology delivers), accuracy exceeded 95%. A connected ontology is not academic.¹ It is what closes the gap between an AI system that guesses and an AI system the business can rely on.

Collibra was built on eighteen years of ontology engineering, well before AI made this urgent. The discipline of governing business meaning across an enterprise (defining terms, mapping them to data, keeping the mappings current, resolving conflicts between domains) is what data governance has been doing for the last two decades. What's new is the consumer. AI systems now depend on that discipline being complete, current and consumable at machine speed.

A connected ontology is built from a specific set of components, and each one exists because something breaks when it's missing:

Business terms and their agreed definitions. The starting point, a documented, agreed meaning for the terms that matter most. Without it, every team defines the term on its own, and "customer" ends up meaning something different in every conversation.

Relationships between terms, including hierarchy and dependency. How terms connect to each other: Linking customers to contracts, products to policies, data to decisions. A customer owns an account, an account has a position, a position is governed by a policy. Without this, an AI system or a person can retrieve a term correctly and still miss the context it depends on, because nothing shows how it connects to anything else.

Ownership and stewardship for each term. A named person or team accountable for a term's accuracy and upkeep. Without it, definitions go stale silently, because no one's actually responsible for noticing.

Links to the physical data assets that represent each term. The connection between a business definition and the actual table, column or document where it lives. Without this link, a definition is aspirational, accurate on paper and disconnected from what's actually stored and queried.

Links to the systems, reports and models that consume them. A record of everywhere a term gets used downstream. Without it, there's no way to know what breaks, or who to notify, when a definition changes.

Policies and classifications that travel with the term. The access rules and sensitivity labels attached to a term, not just to the underlying table. Without this, a term's governance can be perfectly documented and still fail to prevent restricted information from reaching someone who shouldn't see it.

Lineage showing where a value came from. The traceable path from a reported number back to its source. Without it, there's no way to defend or verify a number when someone questions it, which happens more often than most teams expect.

These terms get used interchangeably in a lot of vendor content, and that's a real source of confusion for teams trying to figure out what they actually need. Each one does something specific.

Two of these get contrasted often enough to be worth calling out directly: a semantic layer and a data fabric solve different problems, despite both promising to unify a fragmented data estate. A semantic layer is about meaning and query. It gives a business question a path to the right table or field. A data fabric is an architecture pattern about integration and access. It's concerned with how data physically connects and moves across distributed platforms, not with what any of it means to the business. A connected ontology can sit on top of either, or both, since it operates at the layer of governed meaning rather than physical architecture.

None of these concepts compete with each other, whatever the marketing sometimes implies. A data catalog without agreed definitions tells you where data lives without telling you what it means. A business glossary without links to real assets is a well-intentioned document nobody can act on. A connected ontology is what ties meaning, relationships, ownership and physical location together into something both people and AI systems can actually use, and it depends on the other pieces existing to do it.

Building and running a connected ontology follows a consistent operating flow:

1. Define the business term with the people who use it. Draft the definition alongside the teams who actually work with the term day to day, not in isolation from them.
2. Assign an owner and a steward. Establish who's accountable for the term's accuracy and who handles its day-to-day upkeep.
3. Map the term to the data assets that represent it. Connect the definition to the actual tables, columns or documents where it lives.
4. Express its relationships to other terms. Document how the term connects to the other terms it depends on or informs.
5. Publish it where people and systems can reach it. Make the definition accessible at the point of use, not buried in a separate reference document.
6. Govern change, with review cycles and downstream notification. Establish how and when the definition gets revisited, and how anyone depending on it finds out when it changes.

Some of these steps happen only once per term. They include the initial definition, the first mapping to data and the first pass at relationships. Others run continuously for as long as the term exists: stewardship, accessibility and change governance don't have an end date. Treating the whole thing as a one-time project is the most common reason a connected ontology stops reflecting reality within a year of launch.

A connected ontology shows up wherever an enterprise needs shared, trustworthy meaning rather than each team's private interpretation:

• Getting consistent answers to the same question across departments
• Giving AI assistants trustworthy business context
• Onboarding new data sources without re-litigating definitions
• Surviving a migration or acquisition with two vocabularies
• Proving where a reported number came from
• Scaling governance across clouds and platforms

Each of these gets harder, not easier, as an organization grows and adds more systems, more AI use cases and more teams working from the same underlying data. That's exactly why the ontology needs to be built as durable infrastructure rather than solved once for a single project.

A connected ontology depends on governed business terms actually being connected to something real: stewardship and approval workflows that keep definitions current, lineage that makes a term's history verifiable and clear links between each term and the physical data assets it represents.

Collibra Platform, built on eighteen years of ontology engineering, brings these pieces together in one governed foundation. A business term isn't just documented. It's tied to an accountable owner, traceable back to its source and connected to every system and report that depends on it. The ontology is the digital twin of enterprise knowledge, and it's what carries governed context into every AI system consuming the underlying data.

For unstructured content (contracts, transcripts, emails, PDFs that make up roughly 80% of enterprise data), Deasy Labs extends the same connected ontology approach, building the metadata and governed slices agents need instead of leaving them to parse raw content on their own.

Because no enterprise runs on a single platform, Collibra is built to sit above the stack (governing across Databricks, Snowflake, SAP, Salesforce, AWS, Azure, Google Cloud and on-premise systems) rather than replacing the governance each of those platforms provides for its own environment. A definition of "customer" or "revenue" isn't owned by any single platform. It's owned by the enterprise, and it has to travel with the data wherever an agent reaches it.

Give your enterprise knowledge a governed home with Collibra Data Catalog.

Learn more about Collibra Platform, the enterprise AI control plane.

• Business context and semantic consistency
• AI reasoning, retrieval and context: GraphRAG and ontology-driven AI
• AI data governance: governing business context at enterprise scale
• Context engineering for governed enterprise AI
• What is a business glossary
• Metadata framework: why your AI strategy needs a strong data foundation