This series has spent two posts building an obligation. A data product has to carry context, the definitions and meaning that make it trustworthy. The charter hands that obligation to the steward: capture it. Neither post said where that context comes from.
Most organizations answer that question with dread. They picture a documentation project: a massive backlog of tables to describe and terms to define, never finished because the data grows faster than anyone can annotate it. They see an empty catalog and assume the work is to fill it from scratch.
That assumption is the most expensive mistake in data governance, and it is wrong. The context is not missing. It already exists, in places you already own. The work is not to create it. It is to harvest it before it evaporates.
A data product is not a dataset with a nicer name. It is a managed, reusable asset that solves a real business problem, owned by someone accountable for it, and built to be used by people who did not create it.
That last part matters more than anything else. A pipeline serves the person who asked for it. A product serves everyone who needs it, including people who have not asked yet.
Context Is Already In the Architecture
Every layer of your data architecture generates context as a natural byproduct of moving data through it. You are producing it right now, whether or not anyone is capturing it. It shows up in tiers.
There is structural context: the shape of your data. Column names, data types, table structures, the schema itself. It is fully present the moment a table exists. Nobody has to write it.
There is relational context: how things connect. Foreign keys, join paths, the lineage showing how one dataset was derived from another. Your pipelines encode this every time they run. The relationships don’t need reconstructing. They are recorded in the transformations you already built.
There is semantic context: what the data means in business terms. People assume this layer must be created from nothing, yet most of it already exists in your transformation logic. When a pipeline filters, categorizes, or calculates, it is encoding a business definition. The logic that computes “active customer” is the definition of active customer, written in code, sitting in your repository right now.
There is purpose context: why the data exists at all, what decision it serves, what question it answers. This is the highest tier and the one most likely to live outside the systems, which makes it the bridge to the other place context hides.
The clearest sign that this context is real and harvestable is that platforms have started harvesting it automatically. Snowflake’s Horizon Context and Databricks’ Genie Ontology build a living layer of business meaning from the data, queries, and usage already flowing through the platform. Nobody authors it. It accumulates as the system watches which definitions get trusted, which tables get joined, and which answers hold up. Confluent’s Real-Time Context Engine does the same for data in motion. None of these tools starts with a blank page. They surface the structural, relational, and semantic context the architecture already holds, and teams are pointing their agents at them today.
Read the tiers in order and a pattern appears. The lower the tier, the more the context is already captured in the architecture and just needs surfacing. The higher the tier, the more it lives somewhere the architecture cannot see: in people.
Context Is Already In People’s Heads
Here is the part the modeling frameworks miss. The richest context in any organization is not in its systems. It is in the people who run the business, and they carry it so naturally they do not even know they have it.
A domain expert knows what “active customer” means without looking it up, and knows it differs slightly here from the dictionary. They know which field is unreliable and quietly ignored. They know that in one region, for one historical reason, two plus two comes out to five, and nobody wrote down why. They know which report leadership actually trusts and which is technically correct but never used.
This is the purpose and meaning tier, fully formed and driving real decisions every day. The only problem is that it lives in a person, which means it walks out the door at five o’clock and retires when they do.
Capturing human expertise is not a new problem, and often the people who know a domain best have already solved it. In financial services, FIBO, the Financial Industry Business Ontology, defines the core concepts of finance in a form both people and machines can read, so no firm has to reinvent what a security or a counterparty is. Healthcare has the Vaccine Ontology, which defines how vaccines are understood from research through clinical use, once, for everyone. If you work in one of these industries, a meaningful part of the context you were dreading has already been written. The job is to adopt it, not author it.
The same is true of expertise built across prior work. IBM’s Consulting Advantage packages what has been learned across thousands of engagements into industry-specific assets, agents, and playbooks. How a manufacturer runs operations or a utility manages assets is not unknown. It has been captured, so a team starts from known patterns and tunes them to its specifics. It is the domain expert’s head, at the scale of an industry.
The empty catalog feels daunting because people picture inventing all of this from nothing. They are not. Some of it is encoded in pipeline logic. Some lives in the head of an expert who has been making the call for years. Some has been published by their industry. The steward’s job was never to author context. It was to gather what already exists and write down what is already true.
Why This Makes Everything Faster
This reframe is not just reassuring. It changes the economics of the entire program.
If context has to be invented, building data products and standing up a governance charter is a multi-year documentation slog, and it is easy to see why organizations stall before they start. The blank page looks infinite.
If context already exists and only has to be harvested, the math flips. You are extracting, not authoring. You lift definitions out of the transformation logic that encodes them, turn on the platform features that surface what your systems know, adopt the ontology your industry published, and sit down with the domain expert to capture what they already carry. It is the difference between writing a book and taking dictation, and it is why a data product program can move in months instead of years.
It compounds from there. Reworking a process gets faster because its rules are already documented. Building a pipeline gets faster because its definitions need no renegotiation. Onboarding gets faster because tribal knowledge is written down instead of transferred person to person over months.
Everyone already agrees context is important. The point is that deriving context that already exists, from the systems that recorded it and the people who carry it, turns governance from a cost center into an accelerant. You are not slowing the business down to document it. You are handing back what it already knows, in a form that makes the next thing faster.
Where Data Products, Governance Charters, and Data Context Leaves Us
Three posts, one argument. A data product is the unit: an owned, trustworthy asset the business consumes. The charter is the operating model: the roles and standards that let those products exist consistently. Context is the material they are built from, the thing you were most worried about and least needed to be.
You already have the context. It is in your schemas, pipelines, and transformation logic. It is in the heads of the people who have run the business on it for years. It is in the standards your industry has published. Modern governance is not the work of creating that context. It is the discipline of gathering it before it evaporates, and putting it somewhere both your people and your machines can finally use it.
The organizations that internalize this stop treating governance as a tax and start treating it as leverage. They are not documenting their data. They are harvesting what they already know, and they’re getting faster every time.
Ready to find and leverage the context you already own? Reach out to talk through where it lives in your organization and how to put it to work.
