Architecting the Knowledge Plane for Humans and Agents

In our previous explorations of the Enterprise Information Architecture (EIA), we established the foundation with the Data Plane (treating data as a product) and the structure with the Information Plane (catalogs, products, and marketplaces). Now, we ascend to the final and most strategic layer: the Knowledge Plane.

This is where we move beyond managing data to understanding it. It is the layer that formalizes meaning, context, and relationships, transforming raw information into actionable knowledge.

Why is this layer so critical? We moved from classic data catalogs to data product catalogs and built marketplaces with the objective to promote reuse and composition of assets, making data discoverable and addressable. But even with the best catalog, a fundamental gap often remains: semantic interoperability.

This challenge is intensified by the growing trend of distributing data and responsibilities across the organization. As domains become autonomous, they tend to create their own local definitions and structures. Without semantic interoperability, this distribution results in a fragmented landscape where data products, although accessible, cannot be meaningfully combined. The result is a collection of incompatible silos that hinders the reuse and composition we strive for.

Data is distributed across domains, systems, and technologies. To truly reuse data products across these boundaries, and to empower both human collaboration and AI agents, we need a shared understanding of what the data means. We need to move from a world of implicit knowledge (locked in experts’ heads) to explicit, formal knowledge that humans and machines can understand. Knowledge itself is an asset that has its dignity to not be replicated or built ad hoc inside the specific implementation of agents or tools.

What is the Knowledge Plane?

At its heart, the Knowledge Plane is the home of your organization’s Knowledge Model. It is the layer where you define a shared, common vocabulary that everyone, from business analysts to data engineers, can agree on. But it goes beyond just a list of words; it captures the structure of your business reality.

By formalizing these concepts and their relationships, you create a “semantic twin” of your organization. This allows you to decouple the business meaning from the technical complexity of your data systems.

This is also where the Knowledge Plane becomes strategic. It acts as the bridge between how the business thinks and how your data behaves. It gives AI systems, analysts, and platforms a clear map of what things mean, enabling traceability, interoperability, and explainability across the entire data landscape.

A well-designed Knowledge Plane doesn’t live in isolation. It feeds governance processes, enriches the data product catalog, and provides the foundation for both human understanding and machine reasoning. It ensures that every downstream activity, searching for data, validating metadata, composing data products, happens within a coherent semantic framework rather than in a vacuum.

However, when we talk about implementing this, there is often confusion around the terminology we use: Business Glossaries, Taxonomies, Ontologies, Semantic Layers. They all contribute to the Knowledge Plane, but they serve different purposes and operate at different levels of abstraction.

To simplify, think of it this way:

• Glossary = The words (Vocabulary).
• Taxonomy = The chapters (Classification).
• Ontology = The full story with characters and relationships (Context).

Glossary tells you what — ontology explains how and why.

Beyond the Glossary

Most organizations begin their knowledge journey with a Business Glossary. It’s a sensible first step: a glossary provides a common dictionary of business terms and helps different teams speak the same language. It reduces ambiguity around definitions such as what qualifies as an Active Customer, how to calculate Revenue, or what counts as a Completed Order.

However, a glossary has an inherent limitation: it is flat. Even if it contains hundreds of terms, each entry stands alone. The glossary tells you what a word means, but not how concepts relate to each other or how they fit together in the broader business context.

In practice, this means:

• You can standardize terminology, but you cannot express business rules.
• You can tag datasets with terms, but you cannot explain how data elements interact.
• You can identify what something is, but not what it does or how it connects to other things.

This is where many data teams hit a ceiling. A glossary helps with consistency, but it doesn’t capture the structure of knowledge. It cannot answer questions like:

• A Customer places an Order — how is that represented?
• A Product belongs to a Product Category — what does “belongs to” actually mean?
• A Payment is tied to an Order — what kind of relationship connects them?

To move beyond basic labeling and truly understand the business reality, you need to enrich the glossary with hierarchies, categories, and eventually relationships. This usually happens in stages:

1. Glossary – A flat dictionary of terms.
2. Controlled Vocabulary – Ensuring consistent naming and usage.
3. Taxonomies – Grouping terms into hierarchical structures (e.g., Product → Digital Product → Software License).
4. Ontology – Introducing explicit relationships between concepts, defining how they interact, and forming a knowledge graph (e.g., Finance extends ‘Customer’ into ‘Billing Account,’ linked via hasBillingAccount predicate).

Each step adds a layer of structure and expressiveness.

A taxonomy begins to organize your concepts; an ontology allows them to talk to each other.

That is why the Knowledge Plane cannot stop at a glossary. It requires a model that reflects how the business actually works, not just the words used to describe it.

Only then can metadata, data products, governance processes, and AI systems rely on a shared and consistent network of meaning—one that goes far beyond definitions and becomes a living map of your organizational knowledge.

Semantic Linking vs. Tagging

This shift from glossary to ontology enables a move from simple tagging to semantic linking.

Tagging is often ambiguous because it ignores context. If you have a denormalized table with multiple address columns, tagging them all simply as “Address” tells you what they are, but not which one is which.

Semantic Linking solves this by defining the relationship. Let’s walk through the journey from term to physical column:

1. Glossary Term: Define “Customer” and “Address”.
2. Relationship: Define that a Customer hasAShipping Address.
3. Physical Column: Link the ship_addr column in your database to the “Address” concept via the “hasAShipping” relationship.

Now, the system understands: “This column ship_addr is the shipping address of the Customer.”

Tagging identifies — semantic linking contextualizes.

This distinction is critical in modern analytics, where data is often highly denormalized. By linking data elements to the ontology through specific relationships, you preserve the precise business context that would otherwise be lost in flattened tables. You aren’t just labeling data; you are plugging it into a network of meaning.

How to Build It: The Knowledge Mesh

We are now faced with a paradox. On one hand, the Data Mesh paradigm pushes us to decentralize data ownership to the domains. On the other hand, the Knowledge Plane seems to imply a centralized understanding of the business.

How do we avoid creating a new central bottleneck? The answer lies in Federated Centralization, or what we call the Knowledge Mesh.

Organizational Principles

The Knowledge Mesh applies the same “as-a-product” thinking to knowledge:

1. Domain Orientation: Just as domains own their data products, they must own their local knowledge. The “Sales” domain is the expert on what a “Lead” or “Opportunity” is.
2. Knowledge as a Product: The ontology is not a static document; it is a product that must be curated, evolved, and served to the organization.

Technical Principles

To make this work, we need a platform that supports KnowledgeOps. This isn’t just about drawing diagrams; it’s about operationalizing knowledge management.

Platform Capabilities: The platform must treat knowledge models as first-class citizens. It needs to support:

• Federated Modeling: Allowing multiple teams to contribute to a shared graph without stepping on each other’s toes.
• Publication and Discovery: Making the knowledge models accessible and searchable across the organization.
• Governance: Automating checks on semantic links to ensure consistency.

Shift Left: Crucially, the responsibility for semantic linking must shift left. We cannot rely on central data stewards to document everything after the fact, a process that is slow, error-prone, and rarely scales.

Instead, the domain experts, the people creating the data products, must be the ones to link their data to the ontology as part of the development lifecycle. Just as they write tests and documentation for their code, they should define the semantic meaning of their data before it is published. They know the data best, so they are best positioned to define its meaning accurately. This ensures that every data product enters the mesh with its “semantic passport” already stamped and verified.

The Operating Model: A Lean Approach

How do we organize for this? We recommend a Hybrid Model:

• Central Team: Manages the Core Ontology, the high-level, shared concepts that apply across the entire enterprise (e.g., “Customer”, “Employee”, “Product”). They ensure the “grammar” of the graph is consistent.
• Domain Teams: Extend the core with Domain Ontologies. They define the specific nuances relevant to their area (e.g., “churn risk” for Marketing, “inventory level” for Supply Chain).
• Data Product Teams: Create data products and link them to the ontology. They ensure that the physical data is correctly mapped to the semantic concepts defined by the Central and Domain teams.

Start Small, Think Big

Do not attempt to boil the ocean by modeling the entire enterprise at once. Adopt a Lean Approach.

Instead of building horizontal layers (modeling all concepts, then linking all data), build vertical slices driven by real use cases. Pick a specific business problem (e.g., “Product Inventory” or “Supply Chain Optimization”), model the necessary concepts, link the relevant data products, and deliver value. Then repeat.

Adoption Roadmap

To avoid getting lost, follow this maturity path:

1. Crawl: Establish a Business Glossary. Agree on core terms.
2. Walk: Introduce Taxonomies. Group terms. Start manual tagging.
3. Run: Build the Core Ontology. Implement Semantic Linking for key data products.
4. Fly: Federated Domain Ontologies. Automated reasoning and AI agents.

Avoid these Anti-patterns:

• The Tower of Babel: Every domain builds its own ontology without a shared core.
• The Big Bang: Trying to model the entire enterprise before delivering value.
• The Ivory Tower: Ontologies built by architects without input from data owners.

Conclusion

The Knowledge Plane is the capstone of the Enterprise Information Architecture. By structuring our knowledge through ontologies and operationalizing it via the Knowledge Mesh, we create a semantic foundation that bridges the gap between raw data and business value.

This foundation is not just for better reporting. As we explored in our post on Data Governance and AI Context Engineering, a well-constructed Knowledge Plane is the prerequisite for building reliable, context-aware AI agents. It provides the “brain” that allows AI to navigate your data with the same understanding as your best domain experts.