From Chaos to Context: Where to Begin with Semantic Infrastructure

My current thinking on starting small, derisking the project, and delivering value in a high leverage low stakes place - with your analysts

This weekend I was reading Vin Vashishta’s pieces about enterprise ontologies & knowledge graphs (1 &2), what resonated from his post was his honesty around how traditional approaches can fail amid real enterprise constraints. Though what Vin is talking about (knowledge graphs, agents, ontologies) feels so far from where most enterprises are - which is nowhere near ready to dive into full-blown graphs & ontologies.

The Shopify taxonomy piece is the second most popular article I’ve written - and the most shared - but I struggled with what to write next. There are lots of topics to explore, but I wanted to pick the one that felt nearer to the reality I face in an established enterprise trying to transform for the future.

For so many of us - we’re nowhere near Shopify’s maturity - where does a company like ours even start? Companies like those I’ve worked at have challenges at fundamental levels like:

• Sales & Finance have different numbers for “Revenue” and it leads to a lot of miscommunication and concern when their numbers don’t match

• “Monthly Active User” means three different things depending on who you ask

• New analysts onboard and ask things like “Which customer table should I use for this problem” and got three different opinions and a lot of variants of “It depends…none of this is written down, but here’s a laundry list of things to think about”

This is normal - not ideal - but extremely common at many companies. This has been a pain point for ages, but now this lack of consistency and massive gaps in knowledge curation / context / metadata - is suddenly newly painful and a blocker for adopting the exciting promises of AI powered analytics.

It’s time to prioritize changing the culture and systems around how our companies build shared knowledge - share it, and utilize it. Eventually I hope that will mean for many of us building mature ontologies and queryable knowledge graphs. But today we’re going to take about 1000 steps back, analyze what the real problem is, and determine some early steps we can take on our march toward the agentic workflows and AI powered insights we all want in our business.

---

Naming the Chaos — What “Semantic Ambiguity” Actually Looks Like

I think we all understand the core problem. It’s a similar story over and over — like the revenue numbers not matching:

• Sales celebrates hitting $10M in “Revenue” for the quarter

• Finance reports $7M in “Revenue” for the same period

• Both are right - but they don’t mean the same thing

• Sales focuses on BOOKINGS from signed contracts

  • Because that’s how the sales team is measured on new business they’ve been able to close (future commitments)

• Finance focuses on recognized BILLINGS per GAAP - actual revenue

  • Because they are focused on financial reporting to the board or public shareholders

These departments have different needs, so it’s totally fine to measure and report different figures. The problem is both are using the same word to mean two different things - that’s semantic ambiguity

We face similar challenges with naming objects in the data warehouse. A new analyst joins the company and asks “Which customer table should I use?” They go digging and find five tables—how do they know which one works for them?

• dim_customer (the data warehouse dimension table)

• customer_master (the “single source of truth” that’s 3 months behind)

• customer_360 (the aspirational unified view that’s 60% complete)

• customers_v2 (because v1 had problems nobody documented)

• fct_customer_activity (wait, is this a customer table or an activity table?)

The new analyst asks on Slack and three people respond with three different answers.
The analyst schedules a meeting with a senior analyst to get the “real” answer—which is probably ‘it depends’ (e.g. “if you are doing A you’ll need dim_customer, but if you are doing B you’ll want customers_v2”).

The analyst makes notes in their notebook and proceeds.

Another just in time answer. Still no systematic knowledge improvements.

The impacts of semantic ambiguity make the business inefficient and can drive down trust in data. People may even claim, “We have a data quality problem!” But often the root cause is a semantic ambiguity problem in disguise.

Semantic Ambiguity =/= Data Quality

Truthfully, we may also have data quality problems, but the examples I’m describing here are actually caused by a knowledge gap problem or a lack of structured context. And it’s the ambiguity and confusion that is driving an appearance of data quality problems.

Often the data is perfectly accurate; the pipelines run flawlessly.

Data quality testing won’t fix this.

What fixes this is developing shared meaning as a business through collaboration—through systems that reinforce and improve that shared meaning over time.

Invisible Costs

Semantic ambiguity is a tricky problem to solve because it’s somewhat invisible. We all know there’s miscommunication or disagreement between numbers, but it’s not necessarily clear so many of them come back to a similar root cause.

Instead we just see symptoms of the underlying problems:

• Meetings to reconcile numbers that should already match (or shouldn’t match, but need different names)

• Analysts asking the same questions repeatedly - because answers aren’t documented in discoverable ways (or at all)

• New hires take months to get enough domain expertise to be useful, because we haven’t built structured resources to get up to speed quickly

• Wrong data being used for decisions - because someone used the wrong table because it just wasn’t clear and they used word of mouth context shared instead of having a validated source of truth to turn to

These problems cost the business a lot of money and keep us from helping our customers more effectively.

Despite the costs, these problems persist because they are hard to solve:

• Business terms are inherently contextual

• Teams have legitimate reasons to define things differently (they may not want to converge on a shared definition)

• Driving consensus is hard, slow, and often thankless work - it’s easier to be a hero in the moment fixing the problem than to spend months solving the structural problems.

The ambiguity is painful, but manageable.

The business can muddle through by throwing human labor at the problem to ask clarifying questions and hunt down discrepancies, and while that has never been the most efficient or scalable solution—it is understandable why most companies haven’t gotten around to solving this. And those rare companies that have—like Shopify or Google— there were often a shinier financial incentives that made solving these problems a priority.

For the rest of us, the problems lingered. Until recently, when these problems became more painful. And what changed to bring the pain to the surface: AI.

We want to collaborate with these new promising agents and missing context is a major blocker. While humans can ask clarifying questions when things are ambiguous (“Wait, when you say customer do you mean both B2B and B2C channels??”) AI agents can’t. They miss a lot of ambiguity and confidently make up answers. Even if we can build in logic that directs them to clarify with the user, the business users don’t know how to answer them.

That manual translation step businesses have relied on for decades? It’s now the blocker preventing AI-powered self-service from actually working. So where do we begin?

---

AI Creates a New Opportunity (If You Build the Bridge)

If you are thinking there has to be a better way, you are right, there is. We’ve all seen the demos of Snowflake Intelligence or ChatGPT analysis features:

• Business user asks question in plain language - magically gets accurate answers — no SQL required!

• Analyst drops a dataset into a tool, AI analyzes in seconds - no hand-writing formulas or manually formatting reporting - magic!

• Executive asks “show me our revenue trend year to date” and gets the right answer for their context

• These demos are accurate - it’s not science fiction - the AI capability exists

But we aren’t ready to use it.

The Translation Problem

Today, when a business user asks an ambiguous question a human (usually an analyst) translates that business question into a queryable question. The analyst has to make several jumps to get to that answer:

• Hears: “Show me our revenue trend year to date”

• Recognizes: revenue could mean either bookings or recognized revenue

• Understands context: Todd’s in sales, he probably means bookings

• Finds table: Based on prior experience, knows which table is best for this task. Or asks a friend or if we’re lucky - searches for some documentation somewhere.

• Translates to precise query: Understands the table grain, column meanings, and uses their expertise in SQL to write a query that matches the sales leader’s intent

• Surfaces answer with caveats: “Here’s the bookings trend. This doesn’t account for cancellations.”

For AI to do this same translation work, it needs structured context that explains:

• What “revenue” could mean in different contexts

• Which definition applies based on who’s asking

• Where that data lives and how to query it correctly

The demos that wow us? They either start with perfectly clean data where steps 1-4 are already solved, have hidden semantic layers doing this translation work behind the scenes, or—worst case—are confidently wrong and we don’t even know it.

So if we want to get the benefits of AI in analytics we either limit ourselves to just the final computation layer (but analysts remain a bottleneck for sourcing data) or we have to create a context layer that bridges the gap and allows AI to deliver data with greater accuracy.

We Still Need Analysts

This does not replace analysts— I wrote a whole article about that earlier this fall. Analyst jobs should evolve - from acting like human translators between the business and machines to:

• Helping build this context infrastructure to enable AI at scale

• More strategic partnership with the business

More over here ^👇🏻

The bottleneck here isn’t actually the person (analyst)—it’s the need for manual translation at all.

For years, we’ve tried to solve this by baking analytical logic into pre-built solutions: cubes, flexible dashboards, exports. But those have limits—all it takes is one stakeholder asking “Can you drill through on that?” for you to realize you built the dashboard with too much aggregation—you’re blocked without a decent amount of additional work.

What if instead of baking meaning only into marts, we built semantic structures that describe our business and link to our data? Then both humans and AI have a map. AI can handle routine translation—serving up answers on demand, drilling through, adding dimensions, extending time series. And analysts can focus on complex, strategic problems that actually scale.

The business benefits are obvious:

• Faster time to insight

• More questions answered

• More consistency

• On-demand explanations, reframing, and “drill through” as the line of inquiry evolves

As a platform team you are faced with a decision - how do you start building the missing piece when the piece is so expansive and integral?

The Missing Piece

The AI technology is ready - it’s been ready for a couple of years now. AI is amazing at writing syntax - that’s not the blocker.

The data warehouse has existed for a long time. Though the work never ends (maintenance, new sources, etc), a mature warehouse often has the data you need; it’s not the blocker either.

Your business users want this capability. There’s not a lack of demand - self-service has always been the dream for them and now they see demos within reach.

The missing piece is the semantic infrastructure - the part that helps AI translate its generalized training and understanding into your business context - to help understand what words mean to your business users. Without it - natural language questions are ambiguous and AI guesses confidently which leads to garbage outputs. If we give it a translation layer it can navigate to the right resources and help us bridge the gap.

---

You’ve Got Options - But Only One I’d Recommend

In this moment as a data platform product manager, hopefully you are seeing that AI enabled self-service is critical to enable over the next few years. But you are probably starting from a pretty barren current state - ambiguous definitions, scattered context, and a business that doesn’t really understand the nature of its problem.

You need to chart a path forward. So here are your options.

Option 1: The Ontology Ideal State Path

It’s clear that mature semantic infrastructure like taxonomies, ontologies, and knowledge graphs are powerful assets to have. So one approach would be to hire experts and work through a conventional approach, waiting to build AI on top of your semantic infrastructure until you get a valid ontology.

• Convene cross functional working groups to define terms, with expert guidance

• Build a robust taxonomy

• Drive consensus across the organization on definitions

There’s lots to like about this. Though, it’s a luxury to have an ontologist on staff and their tools are geared to help people with expertise build clean, auditable, precisely defined semantics. It’s an ambitious direction to set your sights on if you are starting from a place of very little curated knowledge, but if the ontology has direct benefits in the product and not just for enterprise knowledge management (e-commerce, content platforms) then you might be able to advocate for budget and a longer investment cycle to ROI. The payoff is bigger there which changes the calculus.

But for most of us this violates one of our key premises in product - which is to start small, ship often, prove value first— and advocate for more resources as you find success. This option requires a lot of up front investment & long lead time to value. There’s a huge risk of not making much progress from a cold start, which undermines future work and wastes resources. So this may not be the right place to start.

Option 2: Act Now, But Sub-Optimally

You could move forward with AI-powered analytics despite the semantic chaos, making compromises to ship something quickly.

This umbrella includes several approaches:

Approach 2A: Deploy and Hope

• Launch AI assistants/chatbots with minimal semantic infrastructure

• Accept that they’ll sometimes give wrong answers

• Plan to iterate and improve based on user feedback

That’s sub-optimal - honestly I’d go stronger and say you’d be better off with almost any other option in this article. Taking a “Deploy and Hope” approach knowing the context limitations create both embarrassing errors and invisible risk is bad for the business and for your team’s brand. It’ll lead to:

• Trust erosion risk: One confidently wrong answer in a high-stakes meeting destroys credibility—possibly permanently

• Black box debugging: When AI gives Finance the Sales definition of revenue, how do you even diagnose what went wrong? Do you even know it went wrong?!

• Compliance exposure: Regulatory requirements demand explainability you can’t provide if the system is guessing

Approach 2B: Limit AI to Final-Mile Analysis Only

• Keep analysts as the data sourcing bottleneck

• Use AI only for the final computation layer (M365 Copilot in Excel, analysis in ChatGPT of datasets analysts have already prepared)

• Solves part of the problem, leaves the translation bottleneck intact

This isn’t the worst option, but it’s still very short term and sub-optimal. Because it doesn’t solve the bottleneck: analysts are still doing all the translation work and this won’t unlock true speed to insight.

• Limited scaling: You can’t democratize data access if users still need analysts to source it

• Underwhelming ROI: You’re using AI for the easy part (computation) while ignoring the hard part (navigation). It’ll maybe be a better use experience (maybe, sometimes it falls flat even here) and it doesn’t have the wow factor.

This approach risks putting business resources behind something that also hurts the data team because we aren’t fulfilling the full vision of what is being said across the business world about the promise of AI for analysis.

Approach 2C: Follow a Single Vendor’s Vision

• Adopt one vendor’s semantic layer/AI analytics solution

• Let them own the context problem within their walled garden

• Works within that tool, doesn’t benefit users who access data through other parts of your platform

This is maybe the least worse option from this group. At least you start to build structured semantics. And if the initiative Snowflake/Tableau and others are working on to make semantic layers interoperable pays off - you’ll be able to make this semantic layer flow and sync with other tools eventually.

It gives you a place to start, you get visible ROI in that tool, and it can scale later. If, however, like many enterprises your company isn’t all using one BI tool - you may not be able to get impact across the whole business, which is deflating. And the cost may be prohibitive. So this is still somewhat sub-optimal. If I worked at a firm that had only a single BI tool with a compelling semantic layer solution I might start here, but every company I’ve worked at has had 2-7+ BI tools at play (yes really, not exaggerating). So practically speaking this may not be viable for many of you.

The fundamental problem with all of Option 2:

You’re shipping something, but you’re either accepting significant risk (2A), leaving the core bottleneck unsolved (2B), or creating vendor lock-in that doesn’t serve your broader platform (2C).

When Option 2 might be justified:

If leadership demands “something with AI” immediately and won’t fund proper infrastructure, Option 2B (final-mile only) is the least-bad choice. It delivers some value without creating the trust/compliance risks of 2A or the lock-in of 2C. But it’s a compromise, not a strategy.

Option 3: Do Nothing

Of course you could just keep operating the way you do today. Maybe you are thinking “I have bigger fish to fry - let’s focus on X, Y, Z.” Maybe no one in the company is clamoring yet, no one has approached you to ask why you don’t have a data chatbot like they saw on YouTube. Execs are happy enough - people resolve the data miscommunication. It’s fine.

It’s definitely tempting - you don’t dilute your efforts from pursuing yet another product direction. You don't put your personal brand behind what might become a fraught endeavor. The current path is less risky and comfortable. The devil you know…and all that.

This is also a terrible choice. It’s riskier than it appears.

Data platforms are expensive to run - it’s critical the team is seen as leading the organization forward to being data driven and, now, AI driven. Your competitors will invest in this infra eventually, it’s only a matter of time before execs start seeing cool data demos and wondering why they still have only static dashboards they sometimes don’t trust.

Building semantics is not something you can do overnight - it’s going to take time. I would not wait, do something even if that something is small.

Additionally, there’s a hidden danger - shadow tool usage. Business users will hook up their own random tools and attempt to run AI analytics off them - not knowing the hidden issues that lie beneath. Analysts will either not document much at all or keep documenting in personal wikis, spreadsheets, and read.me files. You’ll end up with competing incomplete semantic layers, uncontrolled proliferation of partial solutions, and eventually just plain bad data presented out of one of these shadow tools. I don’t recommend Option 3.

---

Option 4: The Reality Most of Us Are Facing - Start Small but Plan for Scale

Look, if you are lucky enough to have a business case + leadership support to go full Option 1 and find a way to build value quickly - great. Most of us don’t have the budget for a full-time ontologist, new suites of tools, and a full dev team to support the work. So we have to find somewhere to start.

To me - the obvious place to begin is to bring some structure within the tools you already have. The data platform team sets the vision and thought leadership for why this is of value, maybe you develop a formal program with milestones/analytics/comms to track progress, and you apply change management starting with your most willing partners and growing the movement over time.

The final section here describes a few guiding principles that may help as you design some early initiatives/features to tackle your semantic infrastructure.

---

Guiding Principles for Data Platform Semantic Infrastructure

Sell the vision

Once you paint the picture for WHY gathering this information is important people are much more excited to participate. People want AI to be able to bring them answers about the business (and self-serve data) but they don’t understand how this missing piece will make that happen. Tell that story repeatedly in different ways until you find the stories that resonate and stick

Choose Tools That Match Your Architecture Goals

Not all catalogs/knowledge management tools are created equal. Evaluate whether your tooling will support the work you’re trying to do.

Key questions:

• Can it handle relationships between concepts (not just flat definitions)?

• Does it support the metadata flows you need (from dbt → warehouse → catalog)?

• Can it integrate with your BI tools, data warehouse, and other systems?

Example: At ResMed, we chose Data.World specifically because its knowledge graph architecture allowed us to model relationships between concepts, not just catalog individual assets. The graph architecture meant every time we defined something “patient-has a-diagnosis” - those were stored as nodes and edges in the graph - as semantic triples that are machine readable. We essentially could build in ways friendly to future ontology builds, without buying custom tools just yet.

Start talking about your tool not as a “data catalog” but as a “knowledge base about how the business works and where our data lives” — a slight change but a meaningful one that started to attract new use cases that wanted to know things like “Can I document a business process in the data catalog?” Having a tool that allowed us to create any resource type we wanted as a node and related it descriptively to other resources (tables, columns, BI reports, other business terms, metrics, etc) meant over time we could create a web of meaning without being too rigid as a platform team. My goal was we were seen as strategic partners for curating knowledge and experts in the tool, but our goal was to partner with the business to document whatever they need.

The principle: Pick tooling that enables the relationships and context flows you need, not just a place to write descriptions.

Design Your Metadata Flow Architecturally

Think systematically about where context originates, where it flows, and what stays in sync.

Key questions:

• What’s editable where and by whom? (Can engineers edit in dbt AND catalog, or just dbt?)

• What syncs happen automatically? (dbt → warehouse → catalog)

• Is it one-way or two-way sync? (One-way is simpler; two-way creates complexity)

• Where is the source of truth for each type of metadata?

Example architecture:

• Technical lineage: Source of truth = dbt, syncs one-way to catalog

• Business definitions: Source of truth = catalog, referenced by dbt/BI tools

• Calculation logic: Source of truth = BI tool semantic layer, documented in catalog

Design in ways that consider your users, their ways of working, and what will integrate most effectively with their ways of working. For example, when we started talking about metadata as code with our source system tech teams - and building it as something they could update programmatically with Github actions, they were thrilled - a way they can document their database via code workflows solved a pain point for THEM not just for their downstream users. That’s a system that’s more likely to stick and be maintained, in fact they had feature requests for us.

Just because you are creating a centralized knowledge base does not mean you are trying to get the entire business to come update it manually like it’s internal wikipedia. That’s not realistic. Design an ecosystem with thought and intention using product practices to interview users and build processes that work.

The principles: Avoid “metadata drift” where the same information lives in multiple places and falls out of sync. Automate as much as possible. Design clear flows with defined sources of truth. Meet your users where they are.

Build for Flexibility, Monitor for Chaos

With multiple people contributing, you need both freedom (so people actually participate) and oversight (so it doesn’t become noise).

The tension:

• Too rigid: People won’t use it (feels like governance theater)

• Too loose: Becomes unusable (duplicate terms, conflicting definitions, no standards)

Design for flexibility:

• Let teams define terms in their own context

• Don’t force premature consensus

• Place some controls (like template design) but develop open communication with the data team to evolve it to better meet their needs over time. It’s controlled for now, but open to evolution.

Monitor for control:

• Who watches for very similar terms that need disambiguation?
  (”Revenue” vs “Rev” vs “Total Revenue”)

• Whose job is it to identify conflicts and drive resolution?

• What metrics tell you the system is degrading? (# of orphaned terms, duplicate definitions, unused metadata)

Who does what here depends a bit on your org structure. In both my companies the experts in the data catalog tool were my governance lead / analysts. Product managers worked on system design and product features (like metadata as code). Engineering adapted their dbt implementation to support writing tags against Snowflake objects (which then automatically flow into the catalog).

The principle: Enable contribution without gatekeeping, but don’t abdicate responsibility for coherence. The central data team leads the overall program and ensures consistency across domains, but they act more as enablers and facilitators than anything else. It’s not about control/management - it’s about collaboration that works.

Version Control and Change Management by Design

Business definitions evolve. Systems change. Calculations get refined. Your semantic infrastructure needs to handle change, not just capture a point-in-time snapshot.

What needs versioning:

• Definition changes (”We redefined MAU in Q3 2024 to exclude bot traffic”)

• Calculation logic updates (”Revenue recognition changed due to new GAAP standards”)

• Deprecated terms (”customer_master was replaced by customer_v2”)

Key capabilities:

• Track when definitions changed

• Track why they changed (link to decision docs, Jira tickets)

• Show what the previous definition was

• Surface which reports might be affected by changes

Example implementation:

• Use git for dbt metadata (built-in version control)

• Require “change reason” field in catalog when updating definitions

• Tag deprecated objects with replacement guidance

The principle: Treat your semantic infrastructure like code—version it, document changes, make evolution traceable.

Where to Test Your Progress: These principles will help you build incrementally. But beyond these small wins & efficiencies, I have a hypothesis for where you can test how well you’re closing the context gap—and you can do that with your analysts.

---

Start Small, Get Early Wins, Evangelize and Scale

There will be limits to this approach, but you’ll evolve when you hit those. The point I hope I’ve conveyed here is that it’s possible to start small and plan for future scale. It’s possible to automate and use humans to curate the business understanding in ways that are readable by humans and machines in the future. It’s possible to start to build the context AI will need to really scale and become more than a copilot — becoming reliable agentic. You have to start somewhere, so do a retro on where you are and brainstorm with your team where the low hanging fruit might lie.

So start small. Start with willing collaborators. Work out the kinks in your processes and systems. Celebrate wins - demonstrate value and get others on board to get more teams involved. The knowledge you curate is useful in small ways early on, and becomes more valuable as it scales and matures across time. Get the members of your central data team to lead by example and get the embedded data professionals engaged.

But beyond these small wins & efficiencies I do have a hypothesis for where you can test out how well you are closing the context gap - and you can do that with your analysts.

With limited context we know AI will make errors in helping retrieve data, but we also know AI is great at writing syntax quickly with enough context. So as you build the structured context, maybe the first use case you pursue is building an assistant just for analysts. The users knows SQL, they are an expert in the business, they probably know a lot of the tables themselves, they are more likely to catch errors and help you iterate on the bot. And it can provide small wins along the way. So maybe it doesn’t actually retrieve data (an access management complexity layer I wouldn’t recommend tackling in MVP), but perhaps it helps:

• Surface likely tables to use

• Suggest which fields may be the right join key

• Draft syntax, calling out areas that are ambiguous and assumptions it had when crafting it (explain your work little bot!)

• Revising syntax with analyst input (Did you account for the fact that a customer can apply more than one discount to a single order?)

• Explaining how long complex queries work (query interpreter)

• Provide suggestions for performance improvement (Use a CTE at the top to apply the where clause earlier so the subsequent steps run on smaller data sets and complete faster)

This is a much lower bar. The context doesn’t have to be perfect because analysts are in the loop to catch errors. They still stand by the work (as they do now) but it can speed up their cycles. I have personally tested this with screenshots from my data catalog & iterating together with ChatGPT - it felt really organic and fun to write so quickly together. And that wasn’t even a custom built bot with instructions and some guardrails and API connection (so I didn’t have to use screenshots).

As a platform product leader - that’s my hypothesis. We start here, we supercharge our analysts and we start building the infrastructure that can scale over time into true ontologies/knowledge graphs and more powerful AI driven workflows and tools that are much more reliable. I’m so excited to build this, I can’t even tell you - and I can’t wait to hear what other platform teams learn as they experiment here too. What a time to work in data.