Semantic Architecture, Knowledge Graphs, and Enterprise Context

This chapter explores how enterprises represent meaning, relationships, and context so that data and AI systems can interpret information consistently. It connects semantic models, ontologies, knowledge graphs, metadata, and context engineering to the broader responsibilities of enterprise data architecture.

Why this chapter matters

Introduction

Enterprise information is not useful merely because it can be stored, moved, or retrieved. It becomes valuable when people and systems can interpret what it represents, understand how it relates to other information, and apply it appropriately to a business situation. This challenge becomes more significant as organizations connect data platforms, analytical applications, generative AI, and increasingly autonomous systems.

A customer, for example, may appear in a customer relationship management system, a billing platform, a risk application, a data warehouse, and a customer service knowledge base. Each system may use different identifiers, attributes, classifications, and definitions. Even when records can be technically integrated, the enterprise may still lack a consistent understanding of what “customer” means in a particular business context, how a customer relates to an account, or which source is authoritative for a given attribute.

Semantic architecture addresses this problem by making meaning explicit. It defines business concepts, relationships, classifications, constraints, and rules that allow information to be interpreted consistently across systems. It provides a bridge between business language and technical representations, helping organizations move beyond data integration toward information interoperability.

Knowledge graphs provide one way to represent these concepts and relationships. They model entities and the connections between them, allowing systems to traverse relationships and answer questions that depend on context. Ontologies and semantic models can provide the definitions and structures that guide how those relationships are represented. Metadata adds information about data assets themselves, including ownership, lineage, quality, sensitivity, and business meaning.

These capabilities have growing importance in AI architecture. A language model may generate a plausible explanation, but it does not automatically understand an organization’s specific definitions, authority structures, product relationships, or business constraints. Semantic models and knowledge graphs can provide structured context that complements document retrieval and vector search. They can help AI applications identify entities, resolve terminology, navigate relationships, and ground answers in enterprise concepts.

Semantic architecture is not a replacement for data modeling, governance, or enterprise integration. It connects and extends these practices. Its purpose is to create a shared and maintainable representation of enterprise meaning that can be used by people, applications, analytics, and AI systems.

14.1 The Need for Semantic Architecture

Large enterprises frequently develop multiple representations of the same business concepts. These differences may arise because business units operate independently, applications were acquired or implemented at different times, or systems were designed for distinct operational purposes. Some variation is legitimate: a customer may have different roles or attributes in different business processes. The architectural challenge is distinguishing useful contextual variation from accidental inconsistency.

Consider the term account. In one system, it may refer to a customer’s financial account. In another, it may mean a corporate customer relationship. In a third, it may refer to an internal ledger account. A data pipeline can move all three records into a common platform, but technical integration alone does not resolve the semantic ambiguity. If an analytical application or AI assistant treats them as interchangeable, the result may be incorrect even when every underlying record is technically valid.

Semantic architecture provides an explicit way to define concepts and their relationships. It helps answer questions such as what an entity represents, how it differs from related entities, which attributes describe it, what relationships are valid, and which definitions apply in a particular context.

This capability supports several enterprise needs. It improves consistency in reporting and analytics, helps systems exchange information, enables more reliable search and retrieval, and provides a foundation for knowledge-driven applications. It can also reduce the effort required to interpret data from unfamiliar domains because concepts are described in business terms rather than only through technical schemas.

Semantic architecture is especially valuable where information crosses organizational boundaries. Shared concepts such as customer, product, supplier, location, employee, agreement, and transaction often appear across many business capabilities. A semantic layer can define common meaning while allowing each domain to maintain the details required for its own operations.

The objective is not to force every system into one universal data model. A successful semantic architecture identifies where shared meaning is essential, where context-specific definitions should remain distinct, and how relationships between these representations should be made explicit.

14.2 From Data Structures to Business Meaning

A data structure describes how information is represented. A semantic model describes what that information means and how it should be interpreted.

A database schema might define a table named CUSTOMER_ACCOUNT with columns for an identifier, status, opening date, and customer reference. This is useful for understanding the physical organization of data. It does not necessarily explain whether the account is a legal relationship, a financial instrument, a service arrangement, or an internal record. That interpretation requires business context.

Semantic architecture connects technical structures to business concepts. It can define the meaning of an account, distinguish account types, describe the relationship between an account and a customer, and specify how account status is interpreted. It can also map the concept to one or more physical representations across systems.

This distinction matters because technical schemas evolve independently. A system may rename a column, change a data type, or split a table without changing the underlying business concept. Conversely, the business may change the meaning of a concept while the physical schema remains unchanged. A semantic layer helps manage these changes by separating business meaning from implementation details.

The relationship can be understood through several levels:

These levels are related but not interchangeable. A physical field named CUST_ID does not, by itself, establish that it represents the enterprise’s canonical customer identifier. That mapping must be documented and governed. A mature semantic architecture makes these relationships discoverable. It allows a user or system to move from a business concept to its definitions, data assets, owners, lineage, and technical implementations.

14.3 Business Glossaries and Semantic Models

A business glossary is often one of the first practical components of semantic architecture. It provides governed definitions for business terms, including their meaning, ownership, usage, and relationships to other terms. It can reduce ambiguity by making important concepts explicit and accessible across the enterprise.

A useful glossary entry should do more than provide a short description. It may identify the business owner, domain, approved definition, synonyms, related terms, applicable policies, and references to data assets. Where a term has different meanings in different contexts, the glossary should record those distinctions rather than conceal them behind a single broad definition.

For example, “active customer” may mean a customer with an open account in one domain, a customer who has completed a transaction within a defined period in another, or a customer whose relationship remains legally active. These definitions can all be valid for their respective purposes. The glossary should make the context and intended use clear.

A semantic model goes further by representing concepts and the relationships among them. It may define entity types, attributes, relationships, classifications, constraints, and rules. Depending on the use case, it can be represented through conceptual models, logical models, ontologies, knowledge graphs, or other formal structures.

The glossary and semantic model should reinforce one another. The glossary helps people understand terms; the semantic model provides a structured representation that applications can use. If these capabilities are managed independently, definitions can drift. A governed process should connect business terms to the corresponding model elements and data assets.

The level of formality should match the purpose. A glossary may be sufficient for an initial business vocabulary initiative. A more formal semantic model may be required when systems need machine-readable definitions, relationship reasoning, or consistent interpretation across domains.

14.4 Ontologies and Enterprise Concept Models

An ontology is a formal representation of concepts within a domain and the relationships among them. It can define classes, properties, relationships, constraints, and sometimes logical rules that support automated interpretation. Ontologies are used in knowledge representation, semantic integration, and applications where relationships and conceptual distinctions matter.

In enterprise architecture, an ontology can provide a shared vocabulary for a business domain. For example, a financial services ontology might describe customers, legal entities, accounts, products, agreements, transactions, obligations, and regulatory controls. It can define relationships such as a customer holding an account, an agreement governing a product, or a transaction affecting an account.

The value of an ontology is not simply that it contains more detailed terminology. Its value comes from expressing relationships and constraints in a form that can be consistently interpreted. If an application needs to determine which agreements govern a particular product, an ontology or related semantic model can make the relevant relationship explicit.

Ontologies can also distinguish between concepts that appear similar in ordinary language but have different business meanings. For example, a person, a legal entity, a customer, and an account holder may be related, but they are not necessarily interchangeable. A person may represent a legal entity, act on behalf of an organization, or hold an account without being the enterprise’s contracting customer.

The design of an ontology requires business participation. Architects and knowledge engineers can define formal structures, but domain experts must validate whether the concepts reflect actual business meaning. The model should also be tested against real information and real questions. A model that is logically elegant but disconnected from operational language will be difficult to adopt.

An ontology should not become an attempt to model every possible enterprise concept in one exhaustive structure. Large models can become difficult to govern, slow to evolve, and disconnected from the needs of specific applications. A more practical approach is to establish shared foundational concepts and develop domain-specific models that connect to them through explicit mappings.

14.5 Knowledge Graphs: Representing Entities and Relationships

A knowledge graph represents information as entities and relationships, often with properties attached to both. This structure makes relationships first-class elements of the information architecture rather than treating them only as joins between tables or references embedded in documents.

A simple graph might represent a customer, an account, a product, and a transaction. The customer is associated with the account; the account is linked to a product; and the transaction affects the account. These relationships can be traversed to answer questions that involve several connected concepts.

For example, a business user might ask which products are associated with customers in a particular segment, or which agreements govern a product offered in a specific jurisdiction. A knowledge graph can represent the entities and connections required to navigate such questions.

A graph typically contains nodes and edges. Nodes represent entities or concepts, while edges represent relationships. Properties can describe attributes such as identifiers, dates, classifications, or status. The exact data model depends on the graph technology and the use case.

Knowledge graphs can support multiple forms of information. They may represent master data relationships, business concepts, document references, operational events, or analytical relationships. However, combining these into one graph requires careful decisions about identity, ownership, update frequency, and meaning.

The graph should also preserve provenance. A relationship may come from a trusted master data system, a transactional event, a document extraction process, or an inference. These sources do not necessarily have equal authority. A robust architecture records where graph facts came from, when they were observed, and whether they have been validated.

A knowledge graph is not automatically an enterprise-wide source of truth. It may be a derived representation that integrates information from multiple authoritative systems. The architecture should make clear which systems own the underlying facts and how graph updates reflect changes in those systems.

14.6 Graph Models, Identity, and Relationship Governance

The usefulness of a knowledge graph depends on the quality of its entity resolution and relationship definitions. If two records representing the same business entity are treated as separate nodes, the graph may fragment important relationships. If distinct entities are incorrectly merged, it may create false connections.

Entity resolution is the process of determining whether different records refer to the same real-world entity. It can use identifiers, matching rules, reference data, probabilistic methods, and human review. The appropriate method depends on the data and the consequences of an incorrect match.

Identity should be designed with domain context in mind. A person may have multiple roles, identifiers, and relationships across the enterprise. A legal entity may have branches, subsidiaries, trading names, or jurisdiction-specific registrations. A graph should not assume that a single identifier always captures every relevant identity distinction.

Relationship governance is equally important. A relationship such as “owns,” “manages,” “controls,” “supplies,” or “is associated with” must have a defined meaning. In some domains, relationships are time-dependent. A person may have managed an account during one period but not another. A supplier relationship may be active only under a specific contract. The model should represent temporal validity where it matters.

Relationship direction and cardinality also affect interpretation. “Customer holds account” is not necessarily equivalent to “account belongs to customer” in every business context, particularly where joint ownership, delegated authority, or legal representation is involved. The graph should distinguish these relationships rather than relying on ambiguous labels.

The architecture should define who can create, validate, correct, and retire graph relationships. Where graph facts are derived from authoritative source systems, the update process should preserve lineage and reconcile changes. Where facts are inferred, the system should distinguish inference from verified information.

14.7 Semantic Architecture and Metadata Management

Metadata describes data assets and provides context for understanding, discovering, governing, and using them. Semantic architecture and metadata management are closely connected, but they serve different purposes.

Semantic models describe business meaning and relationships. Metadata describes assets and their characteristics, including technical schemas, ownership, classification, lineage, quality, usage, and lifecycle. A business concept may be represented in several datasets, APIs, reports, and documents. Metadata connects those assets to the concept and helps users understand how each representation should be used.

For example, a governed definition of “customer risk category” may be linked to a data product, a source application attribute, a transformation rule, a dashboard, and an AI retrieval index. Metadata can describe the owner, classification, lineage, refresh frequency, and quality status of each asset. Semantic architecture provides the meaning that ties those assets together.

This connection is especially useful for AI. An AI application may need to identify which dataset contains a particular business concept, whether the dataset is approved for its intended use, and what restrictions apply. Metadata can help discover and govern the asset, while semantic models help interpret the information it contains.

Metadata should not be treated as a static catalog that is populated once and then forgotten. Its value depends on accuracy, currency, and integration into the architecture lifecycle. Automated discovery can help capture technical metadata, but business definitions, ownership, and authority often require accountable stewardship.

An enterprise metadata architecture should connect technical catalogs, business glossaries, lineage systems, data quality tools, and semantic models where practical. The goal is not necessarily to consolidate every capability into one product. It is to make the relationships between them usable and maintainable.

14.8 Semantic Architecture for RAG and Enterprise Knowledge Retrieval

RAG systems commonly retrieve content based on textual similarity, keyword matching, or a combination of techniques. These approaches are useful, but they may not fully capture the relationships and constraints that shape enterprise meaning.

A semantic layer can improve retrieval by providing controlled terminology, entity definitions, and domain relationships. It can help interpret that “client,” “customer,” and “account holder” may be related but not identical. It can also identify which product, jurisdiction, or business process a question concerns.

Knowledge graphs can complement document retrieval by connecting retrieved passages to entities and relationships. A question about a product might lead to the product node, its governing agreement, the applicable policy, and the business owner. The application can then retrieve documents associated with those graph elements.

This approach is sometimes described as graph-assisted retrieval or graph-based RAG. It can support questions that require multi-hop relationships, where the answer depends on following several connections rather than finding one semantically similar passage. For example, determining which policy applies to a product offered through a particular subsidiary may require connecting the product, legal entity, jurisdiction, and policy.

The architecture must still validate the quality of the graph and the authority of its relationships. A graph query can return a structurally valid path that is based on stale or incorrectly resolved data. Graph-based retrieval does not remove the need for source governance, lineage, and evaluation.

Semantic context can also be used during query interpretation. The application may identify entities and business terms in a user question, map them to governed concepts, and use those concepts to guide retrieval. This can improve consistency, particularly when users employ informal terminology or abbreviations.

A practical architecture often combines several capabilities: vector retrieval for conceptual similarity, keyword search for exact terminology, graph traversal for relationships, and structured queries for precise current values. The application selects or coordinates these methods according to the question and the controls required.

14.9 Context Engineering and the Meaning of Enterprise Context

Context engineering is the practice of designing and managing the information supplied to an AI system so that it can perform a task within the intended business and operational boundaries. It includes more than prompt wording. It involves selecting relevant information, preserving relationships, managing context size, representing user and task state, and distinguishing authoritative information from assumptions.

Enterprise context can include several categories. There is user context, such as role, permissions, and relevant preferences. There is business context, such as domain, product, process, jurisdiction, and organizational unit. There is information context, including definitions, source documents, metadata, and lineage. There is task context, including the user’s request, prior steps, constraints, and expected output. There is also operational context, such as the tools available to the application and the actions it is permitted to perform.

These categories should not be collapsed into one undifferentiated prompt. Each has different governance requirements. User permissions should be enforced by the application, not inferred from text. Business definitions should come from governed sources. Task instructions should be controlled by the application design. Retrieved content should be treated as evidence rather than trusted instruction.

A semantic architecture can make context more precise by defining the concepts and relationships that matter to a task. For example, an AI assistant supporting a product specialist may need to understand the relationship between product, customer segment, eligibility rule, jurisdiction, and policy. Without those relationships, it may retrieve documents that share terminology but do not apply to the user’s question.

Context should also be time-aware. An answer about a current policy may require the latest approved version, while a historical analysis may require the version that applied at a particular date. A semantic model can define the relevant temporal relationships, and metadata can identify effective periods.

The architecture should aim for context that is sufficient, relevant, traceable, and appropriately scoped. More context is not always better. Excessive or conflicting material can confuse the model, increase cost, and obscure the evidence that matters. Context engineering is therefore an information selection and governance discipline as much as a prompt design activity.

14.10 Semantic Interoperability Across Domains

Enterprise-wide consistency does not require every business domain to use identical models. Different domains have different responsibilities and may legitimately define concepts at different levels of detail. Semantic interoperability allows these domain models to communicate through explicit mappings and shared concepts.

A domain-oriented approach can establish a small set of enterprise concepts that are important for cross-domain exchange. Each domain maintains its own model and maps relevant elements to the shared vocabulary. This avoids requiring every team to adopt a single physical or logical schema while still enabling meaningful information exchange.

For example, a retail banking domain and a corporate banking domain may both use the concept of customer, but their operational definitions and attributes may differ. The enterprise model can define the shared concept and clarify how domain-specific customer representations relate to it. The architecture should not erase meaningful distinctions simply to create a uniform label.

Mappings can be simple correspondences between terms, or they can involve more complex transformations and rules. A mapping should identify the source and target concepts, the relationship between them, any transformation logic, and the limitations of the correspondence. A mapping that is approximate should be labeled as such rather than presented as exact equivalence.

Semantic interoperability also supports mergers, acquisitions, partner integration, and modernization. When systems use different concepts or classifications, explicit semantic mappings can help preserve meaning during data migration and integration.

The enterprise architect’s role is to establish the governance and design principles that make these mappings manageable. This includes deciding which concepts require shared definitions, who owns them, how domain exceptions are handled, and how changes are communicated across dependent systems.

14.11 Semantic Architecture Patterns and Technology Considerations

Semantic architecture can be implemented through several complementary patterns. A governed business glossary provides shared terminology. A semantic layer maps business concepts to data assets and measures. An ontology formalizes domain concepts and relationships. A knowledge graph stores and connects entities and facts. A metadata catalog describes the assets and their governance characteristics.

These patterns may be implemented in separate tools or integrated platforms. The architecture should be guided by required capabilities rather than by the assumption that one product must provide every semantic function.

A semantic layer is often useful in analytics, where it provides consistent definitions for measures, dimensions, and business entities. It can reduce the risk that different reports calculate the same metric differently. However, the semantic layer must have clear ownership and change management, particularly when definitions affect executive reporting or regulated disclosures.

Knowledge graph platforms may be appropriate when relationship traversal is central to the use case. Selection criteria include the graph model, query capabilities, scalability, transaction and update behavior, integration, security, lineage, and operational skills. The architecture should also consider whether the graph is authoritative or derived.

Ontology technologies can support formal semantics and reasoning, but their value depends on the problem. A highly formal ontology may be justified in domains with complex relationships, interoperability requirements, or rule-based reasoning. For a straightforward glossary or reporting use case, a simpler model may be more practical.

The key trade-off is between expressiveness and manageability. Rich semantic models can represent complex meaning, but they require stewardship, versioning, and adoption. A model that is too simple may fail to capture important distinctions; a model that is too complex may become difficult to maintain and use.

Technology choices should also consider integration with existing data catalogs, governance workflows, identity systems, APIs, data products, and AI platforms. Semantic architecture should become part of the enterprise information ecosystem rather than an isolated modeling initiative.

14.12 Semantic Governance and Lifecycle Management

Semantic models evolve as the business changes. New products, regulations, organizational structures, and operating practices can introduce concepts or alter existing definitions. A semantic architecture therefore requires governance that supports change without creating unnecessary bureaucracy. Governance begins with ownership. Each important business concept should have an accountable owner or steward who can validate its definition and approve material changes. Technical modelers can manage the formal representation, but they should not independently determine business meaning.

Versioning is important when semantic definitions are used by multiple systems. A change to the meaning of a term may affect reports, data products, APIs, graph relationships, retrieval indexes, and AI prompts. The organization should be able to identify dependent assets and assess the impact before a change is released.

Semantic changes should be classified by their effect. Some changes clarify documentation without altering meaning. Others add optional attributes or relationships. More significant changes may redefine a concept, split one concept into several, or change the meaning of an existing relationship. The governance process should match the level of impact.

A semantic model should also be tested. Tests may verify that required relationships exist, identifiers are unique within defined scopes, mappings are complete, and domain constraints are respected. For knowledge graphs, validation can examine whether expected relationships are present and whether prohibited or inconsistent relationships have been introduced.

Adoption is another governance concern. A semantic model provides value only when applications and teams use it. The architecture should make semantic definitions accessible through catalogs, APIs, modeling tools, and developer workflows. It should also provide practical guidance for mapping local models to shared concepts.

Semantic governance is most effective when it is integrated with enterprise data governance, data product management, and architecture review. It should not become a separate approval process that slows every change. Its purpose is to preserve meaning and interoperability while allowing domains to evolve.

Case study: Meridian Financial Group

14.13 Semantic Architecture at Meridian Financial Group

Meridian Financial Group is a fictional global financial services organization with fragmented customer information, multiple product systems, and an expanding portfolio of AI applications. Its business units use overlapping terms, but the definitions and relationships behind those terms are not always consistent.

Meridian’s architecture team begins by identifying a limited set of cross-domain concepts that frequently appear in reporting, integration, and AI use cases. These include customer, legal entity, account, product, agreement, transaction, jurisdiction, and policy. Domain representatives review the definitions and identify where the concepts have distinct contextual meanings.

The team creates a governed business glossary and links its terms to existing logical models, data products, source systems, and metadata catalog entries. It avoids forcing all domains into a single model. Instead, it establishes shared definitions where interoperability is required and documents domain-specific extensions where business processes differ.

Meridian then develops a knowledge graph for a focused use case: understanding relationships among products, legal entities, jurisdictions, agreements, and policies. The graph is populated from governed source systems and approved document metadata. Each relationship retains provenance, including its source, effective period, and validation status.

The graph supports an internal knowledge assistant. When an employee asks which policy applies to a product in a particular jurisdiction, the application identifies the relevant product and jurisdiction, traverses the graph to locate associated agreements and policies, and retrieves supporting document passages. Vector and keyword retrieval are used to find relevant content within those documents. The model receives the retrieved evidence along with source references and instructions to distinguish established facts from uncertainty.

During implementation, Meridian discovers that two business units use the term “customer” differently. One model treats a customer as a contracting legal entity; another treats a customer as an individual or organization receiving a service. Rather than selecting one definition as universally correct, the team models the distinctions and defines the relationships between customer roles and legal entities.

The organization also discovers that some graph relationships are time-sensitive. A policy may apply only during a defined period, and a product may be offered by different legal entities in different jurisdictions. The graph model is updated to represent effective dates and applicability. Historical questions can then be answered using the relevant time period rather than assuming that current relationships always applied.

Meridian establishes a governance process involving domain stewards, enterprise architecture, data governance, and AI product teams. Material semantic changes are reviewed for their impact on data products, reporting, graph applications, and retrieval workflows. The team also defines validation checks for source lineage, required relationships, and temporal consistency.

The result is not a single enterprise model that replaces every domain representation. It is a governed semantic capability that makes important concepts and relationships discoverable and usable across systems. For Meridian, the knowledge graph is valuable because it connects business meaning to authoritative information and supports more contextual AI retrieval.

14.14 Practical Artifact: Enterprise Semantic Architecture Assessment

This assessment can be used to understand the current state of semantic architecture and identify capabilities required for a proposed initiative. It is intended to support discussion among enterprise architects, data architects, domain owners, governance teams, and AI product teams.

The assessment should produce a prioritized set of decisions. These might include which concepts require enterprise-level definitions, where domain models should remain independent, whether a knowledge graph is justified, and how semantic assets will be integrated with metadata, governance, and AI retrieval.

Remember these

14.15 Key Takeaways

1. Semantic architecture makes enterprise meaning explicit. It connects business concepts to information structures, technical assets, and relationships so that people and systems can interpret information consistently.
2. A business glossary, semantic model, ontology, metadata catalog, and knowledge graph are related but distinct capabilities. They should reinforce one another rather than be treated as interchangeable technologies.
3. Knowledge graphs represent entities and relationships as first-class information. They are useful when a question depends on navigating connections among concepts, but their value depends on identity resolution, relationship quality, provenance, and lifecycle governance.
4. Semantic architecture can improve RAG and enterprise AI by supporting terminology resolution, entity identification, relationship-based retrieval, and more precise context construction. It complements rather than replaces vector search, keyword retrieval, structured queries, and authoritative source systems.
5. Enterprise semantic interoperability does not require every domain to use one identical model. Shared concepts and explicit mappings can enable exchange while preserving meaningful domain differences.
6. Context engineering includes business, user, task, information, and operational context. These categories have different trust and governance requirements and should not be collapsed into an undifferentiated prompt.
7. Semantic assets require ownership, versioning, validation, and adoption. A model that is not maintained or used by delivery teams becomes documentation rather than an enterprise capability.
8. The Enterprise Data Architect’s role is to connect semantic architecture to information architecture, metadata, governance, data products, and AI platform design. The objective is to make enterprise knowledge understandable and usable across the organization.

Think about your own organization

Architect’s Reflection

An enterprise can integrate data without achieving shared understanding. It can centralize information without resolving ambiguity. It can retrieve documents without knowing whether they apply to the business question. These are not primarily storage or connectivity problems; they are problems of meaning and context.

Semantic architecture asks the enterprise to make its important concepts and relationships explicit. That work requires more than choosing a graph database or adopting an ontology language. It requires business participation, clear ownership, disciplined modeling, and an understanding of where consistency matters and where local context must be preserved.

As AI systems become more capable of retrieving, synthesizing, and acting on information, the consequences of ambiguous meaning become more visible. A model may connect information that appears related while missing a business distinction that is essential to the answer. The architect’s responsibility is to make those distinctions available to the system and to ensure that the resulting context can be governed and explained.

The central question is not whether the enterprise should build one universal knowledge model. It is whether the organization can represent the meaning and relationships that matter to its decisions, services, and AI applications—and maintain those representations as the business changes.