Your company doesn't just need more data: it needs more context.
Data has been at the heart of the business conversation for years. We hear about platforms, lakes, lakehouses, data mesh, governance, quality, dashboards, artificial intelligence, and automation. All of that matters. But there's an uncomfortable truth that many organizations discover when they start scaling their AI initiatives: having more data doesn't mean a better understanding of the business. Sometimes it means the exact opposite. More tables, more reports, more pipelines, and more models can create a denser fog if no one has defined what things mean, how they relate to each other, and what rules make an answer acceptable.
The promise of generative AI has made this tension even more apparent. A co-pilot can type a query, summarize a report, or suggest a decision. An agent can chain steps, query systems, and return a seemingly convincing answer. But if that system doesn't know what an active customer is, how operating margin is calculated, or what exceptions apply to a specific region, the result will be beautiful, fast, and dangerous. It's like giving someone a map without a legend: they can navigate roads, but they can't distinguish a highway from a ravine.
The thesis of this series of posts is simple: your company doesn't just need more data; it needs more context. Not as a pretty phrase for a presentation, but as a real capability that helps teams speak the same language, reduces rework, improves the quality of analyses, and transforms copilots and agents from friendly assistants into reliable colleagues. In this first article, we explore why data, on its own, has a clear limit, and what "context" truly means in a business.
Without semantics, there are no reliable decisions.
A table can be technically flawless and yet ambiguous from a business perspective. It might have correct column names, consistent data types, and well-defined access controls. But if no one knows whether "customer_id" represents the buyer, the contract holder, the payer, or the end user, the data isn't ready for decision-making. It's ready to be stored. That's not the same thing.
The difference seems small until an organization tries to automate decisions. In a committee, ambiguity can be resolved by asking a question. On a dashboard, someone detects a discrepancy and calls the data team. But in an AI agent, ambiguity can silently travel from question to answer: the user asks in natural language, the agent generates a query, the result is sorted and everything seems reasonable, but the underlying meaning may be wrong.
For years we've compensated for this lack of semantics with people: analysts who know the business, architects who know where the pitfalls are, data managers who remember which systems are reliable. That human memory has been the invisible glue of many architectures. It works as long as the volume of changes is manageable. But when self-service scales and LLMs are connected to internal systems, that glue becomes insufficient.
Data without semantics has three clear limitations. The first is interpretation: two teams can look at the same data and reach different conclusions because they use different definitions. The second is reuse: each new use case rebuilds meaning from scratch. The third is automation: a machine can operate with structures, but it needs context to know which structures are relevant and which rules apply.
The paradox is that many companies invest heavily in moving data, but very little in explaining it. They build information superhighways, but not traffic signs. They have catalogs with thousands of assets, but few living definitions.
From isolated data to actionable context
AI doesn't just need columns: it needs meaning, rules, and traceability to respond with sound judgment.
Key message: Moving data is necessary; explaining data is what enables decision-making and automation to be scaled up.
When the same metric means different things
Few things generate more friction than a metric that's only shared in name. "Revenue," "sales," "churn," "active customer," "margin": these seemingly simple words actually mask complex business decisions. Does revenue include discounts? Is a customer with a suspended contract considered active? Is churn measured by the number of customers or by recurring revenue?
When these answers aren't formalized, each area ends up fabricating its own version of the truth. Finance sees one figure, sales another, operations yet another. No one is necessarily manipulating the data: often everyone applies reasonable, but not shared, criteria. The problem isn't bad faith; it's the absence of a semantic agreement that answers basic questions: what does the metric mean, what is its formula, what granularity does it allow, what source is authoritative, and who maintains it?
Without that contract, analytical self-service becomes interpretive self-service. And AI doesn't magically fix this; it can amplify it. An LLM is extraordinary at finding linguistic patterns, but can't guess which internal definition the steering committee approved if that definition isn't available and connected to the data. That's why the conversation shouldn't start with "What AI model do we put on top of this?" but rather with "What meaning do we want that model to respect?"
The invisible cost of asking the wrong questions about data
Asking the wrong questions about data is costly, even though it rarely appears as a line item in the budget: it consumes hours of reconciliation, delays decisions, and erodes trust in platforms. When AI enters the equation, an incorrect answer can escalate much faster than before.
Let's consider an internal agent that allows area managers to query sales data in natural language. The question, "Which stores have improved the most this quarter?" seems innocent enough, but the agent needs to know if "improvement" means growth in gross sales, margin, or traffic; whether the quarter is fiscal or calendar; and how to handle new stores or returns. If this context isn't modeled, the agent will have to improvise, and while improvisation can be useful in brainstorming, it's not essential for a decision-making process.
Furthermore, the lack of context creates debt: each report that defines a metric on its own creates a small branching point, each dashboard that renames a field separates the user experience from the original meaning. Over time, the company accumulates a jungle of interpretations, and when it comes time to bring in a copilot, that jungle doesn't automatically turn into a garden: the copilot enters the jungle.
The good news is that this problem can be solved by approaching it as an architectural capability: choosing priority domains, formalizing the context with the greatest impact, and integrating it into the platforms teams already use. The goal isn't to create a perfect encyclopedia. It's to create a living system of meaning.
What is context in business terms?
In a company, context is everything that allows data to be correctly interpreted for a specific decision. It's not just a column description, a glossary, or technical terminology. It's the combination of language, rules, relationships, processes, responsibilities, and constraints that transforms an observation into useful knowledge.
A piece of data reads "42". The context answers: 42 what, measured when, by whom, with what criteria, with what level of confidence, and what reasonable action could be derived from it. The business context has a semantic dimension (concepts and relationships: customer, contract, product), an operational dimension (how these concepts materialize in processes: registration, deregistration, billing), and a governance dimension (who is responsible, what quality is required, what access is permitted).
These dimensions cannot exist in isolation: a glossary without a connection to real data remains a dictionary; an ontology without operational adoption remains a modeling exercise. Value emerges when the context flows from definition to consumption.
Context is not decoration: it is working memory
Context is sometimes discussed as a cosmetic layer: pretty names, labels to help users find things. That helps, but truly valuable context is working memory: it stores the decisions the organization has already made about how to interpret its reality. For example: "a customer is considered active if they have had a valid transaction in the last ninety days" or "profit margin excludes extraordinary logistics costs during clearance campaigns."
When that memory resides solely in people, the company depends on informal conversations. When it resides in semantic models, ontologies, and integrated catalogs, it becomes an infrastructure of meaning. This doesn't eliminate human interpretation; on the contrary, it reserves it for what adds the most value: debating criteria, solving new cases, and refining definitions. The machine can apply known rules, detect inconsistencies, and generate queries, but it needs the organization to provide it with a governed context.
To make this context actionable, it's helpful to break it down into four pieces: definitions (the common language, clear and negotiated with the business), rules (formulas, hierarchies, restrictions), exceptions (because in real-world business there are always exceptions: products that behave differently, countries with specific regulations), and lineage, which should not only indicate the origin of a piece of data, but also its current meaning and its past meaning. These four pieces represent the minimum viable context: there's no need to start by creating a complete ontology for the entire company, but rather to begin where meaning breaks down most frequently.
Understandable data, reliable decisions
Data, on its own, has its limits: it can be clean, governed, and well-stored, and still be ambiguous for business purposes. That ambiguity, invisible to a committee, becomes dangerous when interpreted by an AI agent in seconds. Context—definitions, rules, exceptions, and semantic lineage—is what transforms data into something that can be used to make decisions with confidence.
In the second article of this series, we will delve into the technical aspects: what the semantic model, ontology, and data catalog actually contribute, how they differ, how they coexist in a real architecture, and what role standards such as OWL, SWRL, and SHACL play in converting that context into something that machines can reliably use.
