It didn’t stay simple for long. Someone said a car was sold when the auctioneer’s hammer fell. Someone else said no, it’s sold when finance books the transaction. A third person argued it’s sold when the buyer pays. A fourth said the seller being paid is what makes it real. And then someone asked about returns: if a car came back for a mechanical issue the following week, was it still sold?

Every one of those answers was correct. Not approximately correct, or correct from a certain angle. Correct in a way that mattered to the person giving it, because each one reflected a different business process, a different accountability, a different moment when something real and consequential happened. The auctioneer’s answer served the auction floor. Finance’s answer served the ledger. The seller’s answer served the settlement process. None of them were wrong. None of them were the same.

That meeting is why a company president can pull three reports on the same question and get three different numbers. Not because the data is bad. Because the question “how many cars were sold” has multiple valid answers, each encoded in a different system by people who understood exactly what they were measuring. The reports disagree because the definitions disagree. And the definitions disagree because the businesses they serve are genuinely different.

That’s the moment the unified semantic layer conversation either gets stuck or gets honest.

Every dashboard is already a semantic layer

What usually gets missed in that conversation: the semantic layer already exists. It’s just not where anyone is looking for it.

Every analyst who built a dashboard made a semantic decision. The metric called “30-day active users” in your product analytics tool has a specific calculation behind it. Someone decided what counts as active, what the window is, and whether to deduplicate. That decision is encoded in the tool. It’s just not written down in any format a machine can find or an agent can consume.

The same is true for every calculated field in every reporting tool across the organization. Finance’s revenue definition is embedded in their model. The product team’s engagement metric is embedded in Amplitude or Mixpanel or whatever they shipped last year. Operations has a cost-per-unit definition living inside a spreadsheet someone built in 2021 and has maintained ever since.

None of these are absent of governance. They all reflect deliberate decisions made by people who understood the business problem. The problem is that those decisions are invisible to anything outside the tool that contains them. When an AI agent asks a question that touches multiple domains, it has no way to know which definition to use, whether two definitions that sound the same are actually compatible, or whether the number it just calculated is the same number the analyst calculated last Tuesday.

The recalculation trap

When an agent is asked a question, the easiest path is often to reach back to the raw data and compute an answer. Pull the records, apply some logic, return a number. The problem is that the number it returns isn’t the same number the business uses, because the definition embedded in the raw calculation isn’t the same definition someone carefully encoded in the reporting layer.

Two answers. Both confident. Neither flagged as conflicting. The agent didn’t make an error by any technical measure. It made a governance error that’s invisible until someone compares the outputs and wonders why they don’t match.

The cost problem compounds this. As LLM tools shift from flat-rate to consumption pricing, every query has a real and visible price. Your organization already paid to generate the trusted answer once, when an analyst built the dashboard, chose the definition, and validated the output. That cost is sunk. Every time an agent recomputes the same answer from raw data, you pay again in query compute and LLM tokens. And you get a different number. You are paying more to be less trustworthy.

What actually erodes confidence over time is the version problem. If your organization has a trusted dashboard that answers a specific question, and an agent answers the same question differently, you now have two sources of truth competing silently. Not with a dramatic failure. With a slow accumulation of “the numbers don’t quite add up” moments that nobody can explain, each one costing money to generate.

The answer isn’t better agents. The answer is telling the agent which definition to use and where that definition already lives. You already paid for that answer. Use it.

Why federation is the only realistic path

Once you accept that semantic decisions are already distributed across the organization, the architectural question changes. It’s no longer “where do we build the one semantic layer?” It’s “how do we make the semantic layers we already have discoverable, registered, and usable by machines?”

Before accepting that, most organizations try the alternative: force new names for contested terms and build a single clean layer around the new vocabulary. If “cars sold” means five different things, stop using “cars sold.” Call them “booked transactions” and “auction settlements” and “funded deals” and define each one precisely. One layer. No ambiguity. Problem solved.

This works. Under the right conditions. We did it with cars sold in a narrow context, with a small team, with enough authority to hold the line on the new terminology. The definitions were precise and the layer stayed clean. The conditions that made it work were real.

The problem is that those conditions don’t scale. As scope expands across more business units and more teams, two things happen. The definitions become increasingly academic, engineered for logical consistency rather than for how people actually think about their work. And the change management cost compounds. Moving people off of words they use every day, words that accurately describe something real in their business context, requires sustained organizational will that is almost never justified relative to the governance benefit. Teams agree in the meeting and revert in practice. The new term lives in the data dictionary. The old term lives in every conversation, every report request, every Slack message where someone asks why the numbers don’t match.

Forced renaming solves a vocabulary problem by creating a translation problem. The underlying semantic difference doesn’t go away. It just gets a layer of terminology on top of it that everyone has to manage in addition to the disagreement itself.

Federation isn’t a compromise position. It’s the accurate description of how knowledge actually works at enterprise scale. Different business units operate with legitimately different definitions because they run legitimately different businesses. A metric used for executive reporting has different requirements than one used for operational alerting. Trying to collapse all of that into a single layer doesn’t unify the organization. It either produces a layer so generic it can’t answer real questions, or it produces a political conflict between teams that each believe their definition is the correct one, with no mechanism to resolve it.

What federation requires is not three parallel things. It’s three things that build on each other.

It starts with local ownership. Whatever tool a team is working in, the semantic decisions they’ve already made get documented and registered in a shared format. Not moved. Not consolidated. Just made visible and machine-readable. This is where the work begins because this is where the definitions actually live.

Local ownership is why a registry becomes necessary. Once definitions exist in multiple places with multiple owners, something has to answer the routing question: for this type of query, from this type of consumer, in this business context, use this layer. That routing logic is where the organizational governance actually lives. Not in the definitions themselves, which belong to the domain owners, but in the rules about which definition applies when. Without the registry, local ownership just produces a more organized version of the same invisible landscape.

And the registry is why identity becomes the constraint. Routing rules that depend on business context need to know which context the consumer belongs to. An agent acting on behalf of a product analyst should get that team’s definitions. An agent acting on behalf of finance should get theirs. Identity is what connects the consumer to the right layer. Most organizations haven’t wired it that way, which is why the identity section below matters. But the dependency only becomes visible once the registry exists to expose it.

The two types of semantic layers, and why they both need to exist

Once you accept that federation is the right model, a second distinction surfaces that most organizations try to avoid making explicit. Not all semantic layers are doing the same job, and confusing the two is where a lot of federation efforts stall.

The business domain problem is about meaning. Two teams use the same word to describe genuinely different business realities. Cars sold means something different to the auction floor than it does to finance. Both definitions are correct. Neither is interchangeable with the other. The federation argument addresses this directly: local teams own their definitions, the registry routes consumers to the right one.

The canonical layer problem is different. It’s not about meaning. It’s about identity and structure. Two teams that have perfectly clear definitions within their own domains try to connect their data across a boundary, and the connection fails because the underlying entity isn’t the same object in both systems.

Consider the word “dealership.” One business might define a dealership as the physical location where customers are sent. Another defines it as the legal business entity that signs contracts. A third defines it as the website domain that hosts the inventory. None of these is wrong. Each accurately reflects how that business actually thinks about and interacts with dealers. But when you try to join customer data from the first system to transaction data from the second, nothing resolves cleanly. You’re joining on a physical address against a legal entity. The grain is different. The meaning is different at the structural level, not just the semantic one.

This is what the canonical layer exists to solve. Not to adjudicate which definition of dealership is correct, but to establish a shared object definition stable enough that data from different systems can connect through it. Without it, every cross-domain join requires custom translation logic, and every new integration starts from scratch.

These are not competing approaches. They serve different consumers with different needs and fail in different ways when they’re missing. A missing business layer produces the cars sold problem: agents and analysts getting different numbers depending on which system they query. A missing canonical layer produces the dealership problem: cross-domain joins that silently return wrong results or fail to resolve at all.

If you force business teams to inherit from the canonical layer, you get definitions too generic to answer real questions. If you force canonical definitions to accommodate every business team’s precision needs, you get definitions so qualified they stop serving interoperability. The governance work is not choosing between them. It’s defining the contract between them. Canonical layers publish shared structural models. Business layers publish their local definitions plus an explicit mapping to the canonical terms when they expose data outside their context. The registry holds both, with routing rules that tell a consumer or agent which layer applies given their question and context.

Expect overlaps, and don’t try to eliminate them

Most rationalization efforts go wrong here. When you inventory the semantic decisions that already exist in your tools, you will find what looks like duplication. Two teams using the same term with different calculations. Two business domains each defining the same entity. The instinct is to ask which one is right and eliminate the other.

Usually both are right, and eliminating either destroys something.

Two business teams using the same term with different logic are almost certainly answering different questions for different consumers. A product analytics team measuring engagement and a finance team measuring billable activity built their respective definitions because they needed precision for different purposes. Forcing a single definition doesn’t resolve the difference. It produces a definition neither team can actually use, and both will quietly work around it.

The same thing happens at the canonical layer. A definition of a customer entity that serves CRM workflows and one that serves transaction settlement can overlap the same underlying record while encoding different consistency requirements. That overlap is expected. The two definitions are not duplicates. They represent different contracts for different downstream uses.

The registry’s job is not to enforce uniqueness. It is to make the landscape legible. A well-designed registry doesn’t tell you there should be one definition of “active customer.” It tells you there are three, who owns each one, what question each one answers, and which one an agent or analyst should reach for given their context. Reducing the number of definitions is the wrong goal. Reducing the number of undocumented definitions is the right one.

The practical starting point

Most organizations don’t need to build anything new to start. They need to do an audit of what semantic decisions already exist in their tools.

What metrics are defined in your analytics platforms? What calculated fields have formal definitions versus informal ones? Where do two teams use the same term with different underlying logic? Where does an agent recalculating from raw data produce a different answer than your trusted reports?

As you build that inventory, classify what you find by type. Is this a canonical definition meant to serve interoperability, or a business definition meant to serve a specific team’s questions? That classification determines where it belongs in the registry and what contract it needs to publish. Without it, you’ll spend time trying to reconcile things that were never meant to be reconciled.

That inventory is the input to the registry. It tells you what needs to be registered before you design any new infrastructure. It also usually surfaces the conflicts that matter most, the ones where two teams believe they have the authoritative definition and neither knows the other exists.

A registry entry doesn’t need to be complicated. For “cars sold,” it might list five versions: auction settlement, booked transaction, buyer payment, seller payment, and net of returns. Each entry names the owner, the business context it applies to, the tool where the definition lives, and a routing rule stating which version an agent should use given the consumer’s context. That’s the whole thing. Not a schema. Not a data dictionary. A legible record of which answer is authoritative for which question, maintained by the people who own the answer.

The governance work here is less about building and more about surfacing. Most of what you need is already written down. It’s just written down in a format only the tool can read.

The dependency you’ll find next

Once the registry exists and the routing rules are in place, the next problem surfaces quickly. The routing rules depend on knowing who is asking. An agent acting on behalf of a product analyst should get that team’s business definitions. An agent acting on behalf of a finance team should get theirs. An agent operating across business units needs to resolve which context applies before it can route to the right layer.

Most organizations will discover, at that moment, that they don’t have a consistent answer to the identity question across their business units. Not because nobody thought about it, but because identity systems were built per-division, per-product, per-tool, and were never designed to interoperate at the semantic layer. Each business unit knows who its users are. The governance layer trying to route a query often doesn’t.

This is not a reason to delay the registry work. The audit, the classification, the registry design are all correct steps and none of them depend on solving identity first. But name the dependency early. The organizations that will stumble are the ones that build the routing logic, go to wire it to identity, and discover the gap then. The ones that name it upfront can sequence the work deliberately rather than hitting it as a surprise.

The routing rules work once you know who is asking. Building the registry is how you find out exactly how much that question matters.

None of this resolves the underlying complexity. The cars sold question still has five valid answers. What changes is that the five answers are documented, owned, and routable rather than silently competing inside systems that don’t know the others exist.

The previous two posts covered the same underlying problem in adjacent territory. The first argued that AI readiness for unstructured data isn’t a curation problem, it’s an epistemic governance problem. The second argued that data governance programs fail when they start with policies instead of business problems. This post is the third part of the same argument. In every case, the problem isn’t that organizations lack information. It’s that the information they have isn’t visible to the systems consuming it.

A semantic layer you can’t find is not a semantic layer. It’s a decision waiting to create a conflict.

The work is to surface it, register it, and route to it. Not to replace it with something central that pretends the organizational complexity underneath it doesn’t exist.

Further reading

The conceptual foundation for why terms can’t be forced into a single definition across different business contexts is Eric Evans’ notion of bounded contexts, introduced in Domain-Driven Design (2003). Martin Fowler’s summary is a good starting point: martinfowler.com/bliki/BoundedContext.html

Zhamak Dehghani’s original data mesh piece is worth reading in full if the source-aligned versus consumer-aligned distinction resonates: martinfowler.com/articles/data-mesh-principles.html

The closest working implementation of the federated pattern in practice is dbt’s combination of Mesh (domain-owned data products in separate projects) and the Semantic Layer (centralized metric definitions that cross-reference those projects). Their documentation on how these work together is worth reading if you’re thinking about tooling: docs.getdbt.com/docs/use-dbt-semantic-layer/dbt-sl

And someone in the room looks at it and thinks: I don’t know where that came from. That doesn’t match what I know. But everyone else is nodding.

If you work in product analytics, you’ve had that experience recently. Probably more than once. And if you’ve been treating it as a minor annoyance, I’d argue you’re misreading what it actually is.

It’s the signal. Not that someone made a mistake. That something structural is changing about how information moves through organizations, and about what the analytical function is actually supposed to do.

AI isn’t just changing what we measure. It’s changing what measurement is for.

The question that used to be tractable

For most of the history of product analytics, we answered a clear question: did people use the feature, and how often? Count sessions. Forecast adoption. Run an A/B test against a usage metric. Ship a recommendation.

The question was hard to answer well. But at least it was clear.

AI-powered features break the question entirely. Usage volume is still relevant, but it no longer tells you whether the product is working. A user who got a confidently wrong answer from a generative feature and never came back looks identical in the data to one who got a great answer and didn’t need to return. The signal and the noise have the same shape.

We now have to assess interaction quality, which requires different instrumentation, different evaluation frameworks, and different skills than traditional funnel or experiment analysis. There is no industry-standard metric for AI answer quality. NPS doesn’t capture it. Session length doesn’t capture it. Thumbs up/down is noisy and gameable.

The field hasn’t standardized, but some signals are proving more useful than others. Task completion rate, measured by whether the user took a meaningful next action after an AI interaction rather than abandoning or immediately repeating the query, captures something session length doesn’t. Downstream outcome correlation, tracking whether users who heavily engaged with an AI feature behaved differently on the metrics that actually matter to the business, is harder to build but closer to the truth. And explicit confidence signals, asking users not just whether they liked the answer but whether they acted on it, can surface quality problems that usage data buries entirely. None of these is a complete solution. But any of them is more honest than a session count.

Product analytics teams are being asked to measure something the field hasn’t solved yet. The teams that build credible frameworks for this first are going to matter enormously to their organizations. The teams that wait for a standard to emerge are going to spend years retrofitting measurement onto decisions already made.

The instrumentation window is closing

There’s a second shift happening that’s less visible but equally consequential.

As development teams move toward AI-assisted formats where code is generated from plain-English specifications, the window for defining measurement is shrinking. Requirements that were informal can now produce large, complex codebases quickly. If you haven’t specified what you’re tracking and why before generation begins, retrofitting instrumentation becomes expensive or sometimes impossible.

Here’s what that looks like in practice. A team generates a feature from a specification in eleven days. It would have taken six weeks the traditional way. Leadership is thrilled. The feature goes to QA. Someone asks, “what does success look like for this, and how will we measure it?” Silence. The spec never defined it. The code generation didn’t require it. Now you’re being asked to retrofit tracking onto something already in staging. You can measure that it ran. You cannot measure whether it worked.

This is a cultural problem as much as a technical one. It means analytics teams need to be in conversations earlier, willing to say “we can’t measure that as written” before a feature is built rather than after. That’s a different posture than analytics has traditionally taken. It requires being upstream of decisions in a way most teams haven’t organized themselves for.

Getting upstream is as much a political challenge as a technical one. Most analytics teams have been trained, implicitly or explicitly, to receive work rather than shape it. Changing that posture requires organizational permission, and earning that permission usually means demonstrating value in the current model before being granted a seat at an earlier table. The teams that have moved successfully have typically done it by solving one upstream instrumentation problem visibly, not by announcing a new strategic position.

Instrumentation is not a technical detail. It is the mechanism by which we either close the information gap or leave it open. And in AI-transformed development, the window to close it is earlier and shorter than it used to be.

The trust infrastructure argument

I want to make a structural argument for why any of this matters, because I think it’s more durable than “analytics is useful” or “data-driven decisions are good.”

In 1970, economist George Akerlof described what happens when buyers and sellers transact with unequal information and no mechanism to close the gap. He showed how used car markets, left without trust infrastructure, collapse toward the worst-quality transactions as good participants exit. He called it the market for lemons. He won the Nobel Prize for the insight.

The reason this matters to analytics is that most of the organizations we work inside are marketplace operators in one form or another. They exist to connect people to things, or to other people, or to decisions. And in every case, the value of the exchange is downstream of the trust underlying it.

Every analytical output we produce either closes an information gap or leaves it open. When it closes one honestly, it builds trust. When it creates a false impression of certainty, it erodes trust in ways that are hard to see until they compound.

AI changes the scale at which trust can be built or destroyed. A single confidently wrong AI output, cited in a leadership meeting and forwarded to three more, spreads in minutes. The organizations that win in an AI-transformed industry will be the ones whose outputs can be relied upon. The ones that lose will be the ones that moved fast and faked it.

Product analytics teams are trustworthiness infrastructure, and that distinction matters.

Trust is what other people decide. Trustworthiness is what we control. Philosopher Onora O’Neill makes this distinction precisely: we tend to focus on building trust when we should be focused on building the conditions that make trust a rational response. We can’t make leadership trust an analytical output. We can make sure our work is verifiable, that we show up before things break rather than after, and that we represent confidence accurately rather than performing certainty we don’t have. When those three things are true, trust follows.

This applies even outside traditional marketplace businesses. Any organization where people make decisions based on information they didn’t personally generate is operating with the same dynamics. The information gap and the trust problem are universal. The scale at which AI can widen or close them is what’s new.

AI is very good at projecting confidence. It is very bad at earning it. The organizations that win will be the ones whose outputs can be relied upon. The ones that lose will be the ones that moved fast and faked it. Product analytics is the part of the system that knows the difference.

The new class of question nobody owns

There is a third shift, one that shows up in the calendar rather than the roadmap.

Leaders now have direct access to AI-powered analytics interfaces that can surface data, generate summaries, and answer questions without going through an analyst. Most of the time that’s a genuine productivity gain. However, AI tools produce answers that sound authoritative at whatever confidence level the underlying data actually supports, and the end user often cannot tell the difference.

Here’s what that looks like. An executive presents a slide showing a specific metric is up eighteen percent. The number came from a natural language query to a BI tool. Three people write it down. After the meeting, an analyst pulls the actual data and gets eleven percent. The discrepancy traces back to the AI tool using a broader event definition than the organization’s standard taxonomy. The slide has already been forwarded. The new metric is already in a press release.

The reactive correction work that follows doesn’t show up in any project plan. It’s hard to staff for because it’s urgent and requires enough context to both reproduce the error and explain it in terms the original audience can trust.

But framing this as a burden misses the more important point about what the analytical function actually does.

Our job is not to achieve perfect data before anyone acts. It is to make sure the confidence level of the information matches the weight of the decision. An 80% confident answer, honestly represented, is often exactly right. What is dangerous is a 60% answer dressed up as certainty. That is precisely what AI tools produce when nobody is calibrating the output.

We are not the team that catches mistakes. We are the team that makes sure the confidence behind a decision matches the actual evidence. Those are different jobs, and the second one is harder to automate.

The jagged frontier problem

Most of the public conversation about AI and knowledge work focuses on the average case: AI raises the floor for average work, so average workers are at risk. That’s roughly true and worth taking seriously.

But Ethan Mollick at Wharton describes something more specific that I think applies directly here: the jagged frontier. AI outperforms expectations on some tasks and falls short on others, and the boundary is not intuitive. You cannot look at a task and reliably predict which side of the line it falls on.

For product analytics, this means the teams that thrive are not necessarily the ones who adopt AI tools most aggressively. They’re the ones who develop a calibrated sense of where those tools can be trusted and where they need a human check. That judgment requires deep familiarity with the underlying data, the business context, and the specific ways AI systems fail.

That is not a skill you can hire in or buy with a tool license. It accumulates over time, in teams that stay close to the data and the decisions simultaneously.

The research from Harvard and BCG on AI in knowledge work makes one more point worth sitting with: AI raises the floor for average work dramatically. A mediocre analyst with good AI tools can now produce output that would have required a strong analyst two years ago. What that means for product analytics teams is that the bar is rising, not staying flat. The work that used to differentiate a strong team is now table stakes. The ceiling, the judgment about what question to ask, whether the hypothesis is correctly formed, whether the instrumentation actually captures the behavior you care about, still requires human expertise.

The answer to “are we being replaced” is not yes or no. It’s: the floor is rising, the bar is rising with it, and the teams that treat that as a clarifying moment rather than a threat are going to be in a fundamentally different position than the ones that wait for someone to tell them what to do.

A note for people earlier in their careers

Most of what gets written on this topic assumes you already have organizational standing to implement it. This section is for people who don’t yet.

The skill that matters most right now is not tool fluency. It’s the ability to look at an AI-generated output and ask the right skeptical questions: where did this come from, what assumptions are baked in, and what would have to be true for this to be wrong? That’s a judgment skill, not a technical one, and it’s built through practice more than training. The analysts who develop it deliberately, who make a habit of tracing outputs back to their sources and stress-testing conclusions before they circulate, are building something that compounds. The ones who optimize for tool adoption alone are building something that depreciates.

The bar is rising for everyone. But the ceiling is still human, and it’s reachable from wherever you’re starting.

A new identity

I’ve been spending time thinking about how to describe what product analytics teams should be orienting toward, and the frame that keeps coming back is this: calibrators, not perfectionists.

Perfectionism in analytics manifests as waiting for certainty before acting, building complete frameworks before shipping anything, treating every error as a failure rather than a signal. That instinct made more sense when the data environment was slower and the stakes of each decision were lower.

Calibration means something different. It means knowing when 80% confidence is enough and when it isn’t. It means reading the terrain of AI tool outputs well enough to know which ones to trust and which ones to audit. It means being upstream of decisions enough to shape the questions before the wrong answers circulate. It means being honest about uncertainty rather than performing certainty you don’t have.

That last piece, honest representation of confidence, is the core of the trustworthiness argument. An organization that knows exactly how confident to be in its data, and acts accordingly, is more trustworthy than one that always claims certainty or always hedges. The calibration is what closes the information gap and makes trustworthiness visible enough for others to act on.

The analytical function that endures the AI transition is the one that leans into that identity. Less query writing, more hypothesis design. Less dashboard building, more instrumentation strategy. Less explaining results, more auditing the explanations AI generates. And underneath all of it: the ability to break ambiguous problems into testable hypotheses, which is the skill that has always been at the center of the work and becomes more valuable as the volume of AI-generated claims in the environment increases.

Every one of those claims is either a hypothesis worth testing or a mistake waiting to propagate. The team that knows the difference is the one the organization cannot afford to automate.

Where to start

If you’re trying to figure out what to do with any of this, three things are worth doing now regardless of where your team sits organizationally.

Audit one AI feature your team currently supports and ask honestly: what would a bad answer look like, and would we know? If the answer is “we’d see it in churn eventually,” that’s the gap. Work backward from there to what signal you’d actually need.

Find the next AI feature on your product roadmap and get into the spec review before the build starts. You don’t need a formal invitation. Show up with two questions: what does a successful interaction look like, and what would we track to know? That posture, showing up early with measurement questions, is how analytics teams earn the upstream role.

The next time an AI-generated number circulates in a leadership meeting, trace it. Not to correct it publicly, but to understand the methodology. Build that habit before it’s urgent. The first time you can say “I’ve actually verified that number and here’s the confidence level” will be more valuable than any dashboard you’ve built this year.

A note on these frameworks: they’re directional, not proven. The field is genuinely unsettled, and anyone claiming a complete solution to measuring AI answer quality or defining the evolved analytics role is ahead of the evidence. What’s here is a working model, built from watching these challenges show up in real work. Treat it that way.

The calibration frame

The calibration frame changes what you optimize for. Not fewer errors. Not more certainty. A more honest representation of what you actually know, and a clearer signal about where the uncertainty lives. In an environment where AI tools are actively producing the opposite, that honesty is not a soft skill. It is the technical contribution.

If someone in your organization made a significant decision tomorrow based on an AI-generated insight, would you know? Would you have any way to assess whether the confidence behind that insight matched the weight of the decision? If the answer is no, that’s where the work starts.

My version of a career development conversation, for most of my career as a leader, went something like this. I would ask someone where they wanted to be in a few years. They would say something like “I want a job like yours someday.” I would nod, try not to let on that this was not actually a useful answer, and we would spend the rest of the time talking about how to get from their current level to the next one.

Those conversations were not bad. They were just narrow. Almost every one of them was really a scope conversation: how do I get from specialist to manager, or manager to director? Which is fine, except that those immediate scope moves are exactly what a specialist looks like. They signal someone who has done one thing well for a long time and wants more of the same, just bigger. That is not what ambitious careers are built on.

The deeper problem was that when I tried to suggest lateral moves, people did not know what to do with the advice. “Take a lateral role” is vague in the same way “eat healthier” is vague. It gestures at the right idea without giving anyone anything to do. And when people said they wanted a job like mine one day, what they usually meant was the pay or the title. Not the specific combination of market experience, discipline breadth, and organizational complexity that actually produces that kind of role.

Here is what I eventually understood: most people cannot picture what a different version of their career actually looks like. Not because they lack ambition, but because they have no tool for generating options. When you cannot imagine a concrete alternative, deepening what you already know feels like the safest answer. Specialization becomes the default not because it is the right choice, but because it is the only choice that feels visible. They did not have a real target. They had a sentiment, and a comfort zone that looked like a strategy.

I did not have a better answer for a long time. Then I started showing people my own map, including the gaps. That is when the conversations changed.

The map is simple in concept: every role you have ever held, described across a consistent set of dimensions, laid out across time. Here is what mine looks like across 25 years.

I spent the first six years at AutoTrader.com entirely in retail automotive. Seven roles that mostly shifted one or two dimensions at a time. I understood digital retail deeply. I had no real understanding of wholesale automotive, which is where the majority of vehicle transactions actually happen. The vehicle lifecycle does not begin and end at the dealership. I had been missing the most active part of it for six years without knowing it.

In 2006 I moved to Manheim to work on digital wholesale. It was a scary move. I knew the work would draw on the product management and digital expertise I had built. I also knew some of the leaders there, which helped. But it was a massive change: different market, different customers, different rhythms, different vocabulary for how the business worked.

Five dimensions shifted simultaneously. A framework I did not yet have would have flagged this as high risk. It was. The adjustment period was real. But it was also the most productive growth period of my career. Eight years later I had added analytics, data governance, P&L ownership, people management at scale, and an entirely new business domain to a foundation that had been almost entirely product and operations. None of that was available to me inside retail.

And then there is the dimension that has never moved.

Industry is the one entry on my map that looks identical from 2000 to today. Everything else has shifted. This one has not. I did not set out after college to spend 25 years in automotive. But I have found the industry more genuinely fascinating than I expected, and more meaningful. Dealerships play important roles in their local communities, which sounds like a talking point until you actually spend time with dealers and realize it is just true. Trust is a persistent complaint about the industry, which means the work of building more consistency and transparency is a problem worth solving. One that helps people I know.

Still: I sit with that dimension honestly. It may be the right choice. It may be expertise I have rationalized into a reason not to try something else. Both things can be true simultaneously.

Showing that map to someone, including the uncomfortable part at the end, changed what they were willing to say in response. The conversation stopped being advice from the top. It became two people looking honestly at what careers actually ask of people over time. Nobody feels coached when a senior leader is presenting frameworks at them. People feel something different when a senior leader is thinking out loud alongside them.

Once you have a map, the practical constraint is simple: aim to change one to three dimensions in any given move.

The dimensions group into three categories. Some describe context or where you operate: what market you are in, who your customers are, the type and size of company, whether the organization is in startup mode or mature. Some describe role or how you operate: whether you are an individual contributor or managing a team, whether your work faces internal or external stakeholders, the craft you practice, whether you are building something new or running something that already exists. And some describe scope or the scale of what you operate: your title, team size, budget ownership, how complex and ambiguous the organizational environment is.

Change too few of those dimensions and you are not growing. Change too many and you lose the ability to bring proven skills to the new situation. You go from being someone with relevant adjacent experience to a career changer asking the organization to take a bet. There is also a confidence argument. When a new opportunity feels daunting, and most good new opportunities should, it helps to be able to name specifically what is new alongside the many things that are not. You are not starting over. You are moving your position in a space you have been navigating for years.

The scope dimensions deserve a specific note because they are where most people focus and where they have the least actual control. Title, team size, budget ownership. Organizations decide when they are ready to expand your scope. What you can control is where you operate and how you operate. Doing that work well is what builds the case for scope to follow. Scope is not a reward for tenure. It is what happens when an organization has seen enough of you in enough different situations to trust you with more.

I watch people get genuinely frustrated when a company transitioning from hyper-growth to maturity has fewer open promotions than it did two years ago. A year or two in the same role starts to feel stagnant. The reframe I try to offer: a lateral move is not a failure to move up. It is an investment in having more to offer when the scope opportunity arrives. The people who get promoted and stick are the ones who earned it by building real range. The ones who get promoted by waiting often struggle once they get there or later feel stuck in that single area.

The best proof I have that this works as a coaching tool came from a team member who had spent more than a decade becoming a genuine specialist in consumer web behavior. He had examined that space deeply and built real expertise. The problem was that he had done it for a long time and could not picture what a pivot looked like. The decade of depth felt like it was holding him in place.

We worked through the dimension map together. He was looking at a move toward managing our event stream data from applications. Different customer (internal teams instead of consumers), different domain, different immediate problems to solve. It sounded like a significant change.

But when we mapped the dimensions, most of them did not change. It was still product management. It still required a deep understanding of data behavior and data consumers. The craft was the same. The organizational context was the same. The industry was the same. What shifted was the customer type and the specific domain. One or two dimensions, not ten.

That reframe made the move less frightening. It also gave him something specific to say in the interview, because he could name exactly what transferred and exactly what was new. He made the move. The early returns are real: new enthusiasm, new things being learned, a reinvigorated version of skills he had started to take for granted.

That is what this is supposed to look like.

If you want to try this yourself, start simple. Write down your current role across a handful of dimensions: what market or industry context you are in, who your customers are, what your core craft is, whether you are building something new or running something established, where you sit on the individual contributor to people manager spectrum.

Then look at what has stayed the same across every role you have ever held. Ask if that matters for where you want to go.

Remember, that list is not a record of your limitations. It is your option generator. Pick one or two dimensions you have never moved and ask what a role looks like that shifts those while keeping everything else roughly intact. Most people find the search space opens up considerably once they have a map to work from.

Then bring it into your next one on one. Not as a completed assignment, but as a working draft. Let the conversation be about filling it in together. The point is not to arrive with answers. It is to have a more specific conversation than “I want a job like yours someday,” and to let that specificity do the work that years of vague career advice could not.

I nodded and said something appropriately appreciative and moved on with the conversation. But I have not stopped thinking about that sentence since I got home, because once I understood what it meant, it reframed almost everything I thought I knew about how offshore partnerships actually function.

I had been overseeing a software delivery partnership with a team in Vietnam for long enough to have opinions about it. We had regular meetings. We tracked delivery metrics. We sent requirements documents and received working software in return. The partnership looked functional from where I sat, which is exactly the problem I flew twelve hours to investigate.

The first thing I got wrong was assuming honest feedback would be easy to get

I prepared carefully before the trip. I built a conversation guide. I thought through what I wanted to learn and, more importantly, how I needed to ask in order to get honest answers from a team whose culture does not easily produce criticism in the presence of a senior visitor.

The first meeting confirmed what I had prepared for: every question about the partnership came back positive. Everything was working well. Requirements were clear. Communication was good. The team was happy. It was, in other words, exactly the kind of feedback a senior visitor receives when the team has concluded, probably correctly, that honesty carries more risk than a pleasant non-answer.

I had anticipated this, which is why the preparation mattered. The approach that eventually worked was to stop asking people to evaluate the partnership and start asking them to describe systems. Not “is the requirements process working” but “walk me through what happens from the moment a requirement arrives to the moment a spec goes to an engineer.” Not “do you feel you can raise concerns” but “when something is ambiguous and you can’t get clarification quickly, what do you actually do.” Questions about systems rather than people made honesty feel safer, because the person wasn’t criticizing anyone, they were just describing a process. That shift in framing was the most important preparation I did.

What came out of those conversations was specific and actionable. Two things surprised me enough that I want to share them.

Cars are not cars

Picture a woman in her late thirties. She lives forty minutes outside a mid-sized city in a state where public transit means a bus that runs twice a day. She works a job that requires her to be there at seven in the morning. She has two kids in two different schools. She just got a repair estimate on her car that is eight hundred dollars she does not have, from a dealer whose service department is running three weeks behind. The car is how she does everything. Without it, in a very literal sense, she cannot work, her kids cannot get to school, and a doctor’s appointment becomes a logistical problem she may not be able to solve. She is not shopping for transportation. She is protecting the infrastructure of her entire life.

The team in Vietnam did not have a feel for that person. They understood cars as products. They understood vehicle service as a transaction. What they did not have, and could not have without living in a market built entirely around car dependency, was an intuitive sense of what is at stake for the customer on the other side of the software they were building.

Vietnam’s primary personal transport is the scooter. Ho Chi Minh City has something like nine million of them (and they all cross the road at the same time). The relationship between a person and their scooter is coherent and real. In many structural ways it mirrors car ownership in the United States. Close enough that it’s easy to assume the understanding transfers. It doesn’t, because the stakes are not remotely similar. Nobody’s ability to keep their job depends on whether their scooter starts tomorrow.

I had never made any of this explicit in a requirements document. Why would I? It is so obvious to anyone who has spent time in car-dependent America that it doesn’t feel like context worth providing. It just feels like reality.

And here is the thing that has been bothering me since I got home. I flew to Vietnam to address a context gap on the other side of the world, and in doing so I realized the same gap exists three desks away from me. I have colleagues who have spent their entire careers in cities like New York City or Washington, D.C. where car ownership is optional. These are people who take the subway to work and couldn’t tell you the last time they needed a car to do anything important. They understand the market we serve intellectually. They do not feel it the way someone who grew up where the nearest grocery store is fourteen miles away feels it. The offshore team’s gap was more visible and more complete. But the domestic version has been sitting right next to me, unaddressed, because the people who have the intuition don’t think to say it and the people who need it don’t know to ask. Neither group knows the other exists.

The fix is not a training program. It is a document, written in plain language, that explains what a car means in the markets this industry serves. Not a product spec. A human document about what is actually at stake for the person in the dealership and why. That document would be useful to our offshore partners. It would probably be useful to some of our own people too. We just haven’t written it because it has never occurred to anyone that it needed to be written.

The motivation structure is not what I expected, and that’s the risk

Back to the engineer and what he said about national pride.

The company I visited is one of Vietnam’s largest technology companies. They have a stated mission that includes, in real terms, putting Vietnam on the global technology map. This is not empty corporate language to the people who work there. The engineer who said what he said was not performing company values. He meant it personally. Shipping good software for an American company was, in his mind, evidence that Vietnam belonged in the conversation with the world’s leading technology organizations.

That is a remarkable source of motivation. The team I met was more appreciative, more flexible, more willing to go the extra mile than most domestic teams I have managed. There was a quality of investment in the work that I noticed almost immediately. By the end of the first day I had started to understand where it came from. By the end of the trip I understood why it was the most important management problem I had encountered in years.

A team that cares this deeply about the work, and that is also culturally conditioned not to push back on senior direction or surface problems upward, will work harder and longer in the wrong direction without telling you. The enthusiasm and the silence come from the same instinct. If doing well for your company is connected to your country’s reputation, then admitting that the requirements are unclear, or that the pace is unsustainable, or that the work has been going the wrong direction for two weeks, carries a weight that goes beyond the professional. You don’t say that. You work harder.

When I asked directly about work-life balance and weekly hours, I got the same polished deflection I had received earlier about partnership health. Fine. Good. No problems. I had expected this and didn’t push on it directly. Instead I paid attention to what I could observe. Engineers working hours that would be considered unusual by any domestic standard. A willingness to take meetings and respond to messages at times that suggested the boundary between work and not-work had largely dissolved. Significant time spent outside our project on internal company initiatives, stacked on top of their primary commitments. And then, at lunchtime on one of the days, I walked through the office and saw engineers asleep at their desks.

I learned later that desk sleeping at lunch is not uncommon in Vietnamese office culture, and I want to be careful not to overread it. But in that moment it forced a question I hadn’t planned to ask: was the leadership team aware of how their people were spending their time? The answer, when I found a way to ask it indirectly through a systems framing, was illuminating. The leadership could speak fluently to delivery metrics. They could not speak fluently to sustainability. The metrics were the point. The metrics were perfect.

That is when I understood the real problem. The team had perfect delivery records on our account. Every commitment met. Every sprint completed. No missed targets. On our side, we consider it a sign of healthy estimation when teams miss some commitments. A perfect record doesn’t mean the team is exceptionally capable. It usually means the estimates are padded, the scope is being quietly dropped, or the team is absorbing the gap through hours that don’t show up anywhere. For this team, a missed commitment was apparently unacceptable in a way we had never intended and never communicated. We don’t hold our own domestic teams to that standard. We wouldn’t want to. But nobody had ever told them that.

The team was optimizing with tremendous effort and genuine pride for a signal we had never meant to send. They were building in the dark on ambiguous requirements rather than waiting for clarification, because waiting felt like underdelivering. They were working hours that would concern any manager who knew about them, in service of metrics we would have been happy to see them miss. None of this was in any status report. None of it was visible from Atlanta. All of it became visible the moment I was in the room asking about systems instead of satisfaction.

This means that the positive signals most offshore partnership managers rely on are not reliable indicators of partnership health when the team is motivated this way. High responsiveness, consistent delivery, low friction, absence of complaints: all of these are exactly what a deeply motivated, culturally deferential team produces regardless of what is actually happening underneath. You cannot manage this passively. You have to ask directly whether the pace is sustainable, whether commitments are being met through hours rather than efficiency, and whether there is anything the team has wanted to raise but hasn’t found a safe moment for. And you have to ask in a way that makes honesty genuinely feel safe, which is a different skill from simply asking the question.

The question I came home with

Both observations come down to the same thing: context that is obvious to the people who have it does not travel on its own. Car culture context doesn’t appear in a requirements document. The psychological reality of a motivated offshore team doesn’t surface in a status call. Someone has to go get it, and then figure out how to build structures that make the transfer reliable rather than dependent on a senior leader periodically flying to the other side of the world.

I came home with specific things to fix. The requirements process. The feedback loops. What we actually mean when we talk about delivery commitments. The domain knowledge everyone on our side takes for granted. These are all addressable, and we are working on them.

But the harder question is still sitting with me, and I don’t have a clean answer to it. The engineer who said the work was a matter of national pride is still building software for our company. He is doing it with a level of investment and personal commitment that I suspect most of the people on my side of the partnership don’t know exists. He has attached something that matters to him deeply to the quality of decisions being made in meetings he will never be in, about a product roadmap he has no say in, for users in a country he may never visit.

What do you owe someone in that position? What does it mean to be a responsible steward of that kind of trust when most of the people in your organization don’t even know it’s been extended to them?

I don’t think the answer is complicated in principle. You go. You ask questions designed to make honesty feel safe. You tell them what their work actually does in the world. You fix the things that are broken on your side of the relationship. You treat the metrics skeptically instead of gratefully.

What I know for certain is that you cannot do any of it from Atlanta.

My first reaction was the obvious one: this is fast. My second reaction was the one that stuck: if code can be generated this easily from a spec, does the code itself matter anymore? That question pulled a thread that unraveled something we had spent years building carefully: our composability strategy.

The Original Argument

The composability argument we made, and the one most product and data organizations made, rested on a simple economic premise: writing code is expensive, so write it once and reuse it everywhere.

You simply need to build one pricing service, one inventory availability service, and one consumer identity resolution service. Now any product team, any new solution, any new customer use case can assemble these blocks into something new without rebuilding from scratch. Velocity goes up, duplication goes down, and everyone wins.

This is the Lego metaphor. You invest in a good set of bricks so that builders can make anything they want, faster.

The mistake was hiding in plain sight because we were optimizing for human assembly speed. We assumed the bottleneck was the cost of generating an implementation. And for more than twenty-five years, that assumption was correct. Then it stopped being correct almost overnight.

The Assumption That Broke

Don’t worry, AI code generation has not made composability less important. It has, however, made our original justification for composability mostly irrelevant.

When AI can generate a working implementation from a well-written specification in minutes, the “build once, reuse many times” argument loses most of its force. The bottleneck is no longer the keystrokes. It is now the understanding. Domain knowledge, design decisions, and intent matter.

The reframe that changed how I think about this is straightforward:

Code is increasingly the output of your strategy, not the artifact of it. The specification, the interface contract, and the bounded context are the durable things. The implementation is disposable.

ThoughtWorks’ 2025 Technology Radar specifically identifies spec-driven development as an emerging standard where the specification is the maintained artifact and code is generated and regenerated from it. Andreessen Horowitz described the shift bluntly that code is becoming “more like a compiled artifact than a manually authored source.”

If that is true, and the evidence says it increasingly is, then a composability strategy organized around code reuse is optimizing for the wrong constraint.

The New Customer for Your Architecture

The primary consumer of your composable interfaces is no longer a human developer. It is an AI agent.

Anthropic’s Model Context Protocol (MCP), Google’s Agent-to-Agent Protocol, and the Open Semantic Interchange initiative (backed by Snowflake, Salesforce, dbt Labs, and a dozen others as of late 2025) are all establishing standards for how AI agents discover, invoke, and compose over well-defined service interfaces. These are composability standards built for machine consumption, not human convenience.

When an AI agent tries to answer a business question, it does not read your documentation or intuit your domain model. It hits your interfaces. When those interfaces are clean, bounded, and semantically rich, the agent produces correct, reliable output. If they are ambiguous, monolithic, or semantically thin, the agent hallucinates. Research from Apiiro quantified a 153% increase in design problems in AI-generated code, correlating directly with architectures that lack clear boundaries. Not syntax errors… design problems.

Your composable architecture used to be a developer experience investment. It is now an AI reliability investment.

What Changes and What Stays the Same

When I stress-tested our original strategy against this, a new purpose emerged.

What we were right about: Bounded contexts, API-first design, and separation of concerns are more important than ever (just not because they help developers assemble faster). Instead, they help AI agents operate correctly. Harvard researchers published experimental evidence in 2025 showing that LLMs without architectural constraints produce “architectural mimicry without adherence” (code that looks modular but violates boundaries internally). With enforced constraints, output quality improves dramatically. The boundary is a correctness mechanism as much as it is an organizational one.

What we were optimizing for incorrectly: Code-level reuse metrics (such as: how many times a module gets called or how much duplication got eliminated), are the wrong scorecard now. The better metric is interface stability. You might consider looking at how rarely your contracts change, and how many different consumers, (both human and AI) can compose against them without modification.

What we were missing entirely: Semantic layers. If your domain definitions (what a “customer,” a “price,” a “transaction” means in your business) live inside monolithic systems or under-documented schemas, AI agents cannot reliably access them. The OSI initiative exists precisely because this gap is universal. Your semantic layer is no longer a BI convenience that belongs in debates with human analysts. It is the composable interface your AI strategy now requires.

Where This Lands

Old composability thesis: Build reusable blocks so humans can assemble solutions faster.

New composability thesis: Build governed interfaces so both humans and machines can compose reliably against your platform.

The blocks are still there and the investment in modularity is still justified. But the customer has changed, the scorecard has changed, and the artifacts that matter have changed. The specification is the new source code, and the semantic layer is the new infrastructure.

What To Do About It

If you’re a product or business leader

Audit what your composability investment is actually optimizing for. Pull up the original business case or reconstruct it. If the core argument was “build once, reuse everywhere to accelerate development,” that argument has weakened significantly. If it was “govern our platform so we know what’s running and can enforce standards,” that argument has strengthened. Know which camp you’re in before deciding what to change.

Ask your team one question: “If an AI agent needed to answer a business question using our platform today, what would it hit?” Would it find clean, bounded, semantically defined interfaces or raw schemas it has to guess the meaning of? The answer reveals more about your AI readiness than any roadmap review.

Reframe “reuse” in your investment language. If your teams are still being measured on module reuse rates or duplication reduction, those metrics will steer them wrong. The goal is no longer avoiding redundant code. It is ensuring your domain knowledge is expressed in stable, machine-readable forms. Fund interface governance the way you used to fund shared libraries.

If you’re a data practitioner

Treat your domain definitions as versioned, governed artifacts rather than documentation. Whatever canonical concepts power your business (your “customer,” your “deal,” your “price”), those need to exist as machine-readable, authoritative specifications. A wiki page is not enough anymore. If an AI agent cannot programmatically discover what your organization means by a core concept, that gap will show up as hallucinations in production.

MCP connectivity is table stakes. Semantics is the real problem. By mid-2025, every major data warehouse had shipped or announced Model Context Protocol support, so connectivity is no longer the gap. The problem is that MCP gives AI agents a door into your platform, but if your semantic definitions are thin or missing, the agent walks into an unlabeled warehouse. A protocol without semantics is just faster confusion at scale. The investment that matters is not “can an agent reach our data” but “when it does, does it find authoritative definitions of what that data means.” Most teams are not having that conversation yet.

Shift your architecture metrics from reuse to stability. Count how rarely your interfaces change and how many consumers can compose against them without modification. A stable, well-specified interface an AI agent can reliably invoke is worth more than a cleverly reused implementation. That reorientation sounds subtle, but it will change which technical decisions you advocate for.

Composability was never really about the bricks. It was about making complex systems understandable, governable, and changeable. AI has made that mission more urgent. We just needed to update our mental model of who is doing the assembling.

We tried something different. We started with the business problems and worked backwards. Specifically, we started with AI and ML use cases that required clean, structured, connectable data across domains. That framing changed everything.

The Insight That Changed Everything

Here’s what we realized: data governance doesn’t fail because organizations lack frameworks or tools. It fails because nobody can articulate why it matters. When you ask an engineering team to fill out metadata forms, their first question is “why should I care?” And “because it’s policy” is not a compelling answer.

But “because we need structured, connectable data to train ML models for these five initiatives the CEO cares about”? That’s a different conversation.

So we flipped it. Instead of asking “what governance do we need?”, we asked “what AI and analytics capabilities are we trying to build, and what’s preventing our data from supporting them?”

Starting With the End in Mind

We identified about ten high-impact use cases the business actually wanted to build. Things like AI-powered recommendations, inventory optimization, demand forecasting. Real initiatives with executive sponsorship and budget. Then we mapped out the data each use case needed.

That’s when things got interesting. As we traced through data requirements, we started seeing patterns. The same data families kept surfacing across multiple use cases. Customer data was needed for six different initiatives. Product catalog data showed up in eight. These weren’t arbitrary governance targets. These were genuine bottlenecks.

But here’s what really mattered: these use cases didn’t just need customer data or product data in isolation. They needed to connect customers to products, products to inventory, inventory to transactions, transactions back to customers. AI models need to understand relationships across domains. A recommendation engine can’t work if you can’t reliably link a customer’s purchase history to product attributes. Demand forecasting breaks if inventory IDs don’t map consistently to product catalogs.

The value wasn’t in having clean data in individual silos. The value was in having structured, connectable data that could flow across domain boundaries. That meant standardized identifiers, consistent schemas, and clear relationships between entities.

We built what we called a “data domain map,” essentially a comprehensive view of all the data families across the enterprise. Then we overlaid each use case’s data needs onto this map. Suddenly we could see which domains mattered most and, critically, which connections between domains were blocking the most value.

Finding the Real Problems

The next step was identifying gaps. For each high-priority use case, we catalogued the specific data issues preventing it from succeeding. Not theoretical data quality problems, but concrete blockers to AI and ML capabilities.

For a cross-selling initiative, we found specific issues: customer duplicates across regions, no structured product catalog, missing relationship data, incomplete customer hierarchies. Each problem had a clear connection to why the use case couldn’t deliver value. But more importantly, each problem represented a failure of data connectedness. You can’t train a recommendation model when the same customer appears three times with different IDs, or when products lack standardized attributes that enable feature engineering.

We repeated this across all priority use cases. The backlog of data issues grew, but it was a prioritized backlog based on what was actually blocking AI capabilities.

Then we aggregated. When the same data family appeared across multiple high-value use cases, it jumped to the top of our governance roadmap. When a data domain only impacted one low-priority initiative, it stayed low.

What emerged was a clear picture: the highest-value governance work wasn’t about perfecting individual datasets. It was about establishing the structured foundations and cross-domain connections that AI use cases depend on: Standardized entity IDs. Consistent timestamp formats. Clear schema contracts between producers and consumers. The boring infrastructure work that makes automated systems actually work.

Governance as Product Development

Once we knew which data mattered and why, we could actually design governance initiatives that people might care about.

For customer data, we weren’t asking teams to “improve data quality” in the abstract. We were asking them to help ship five specific AI-powered business initiatives worth millions in potential revenue. And we could be explicit about what “AI-ready” meant: unique identifiers that enable entity resolution across systems, standardized schemas that support feature engineering, temporal consistency that enables time-series modeling, and clear lineage that makes outputs explainable.

That’s a conversation engineering teams will engage with. They understand why ML models need structured inputs. They get why inconsistent data types break automated pipelines. They see the connection between good data practices and being able to ship innovative capabilities.

We built the governance roadmap directly in sync with the use case roadmap. As each wave of AI and analytics initiatives launched, we’d remediate the specific data structure and connectivity issues blocking them. The governance work had a direct line of sight to business value, and crucially, a timeline that matched business needs.

This meant we could finally answer the “what’s in it for me” question that kills most governance programs. For the business: your initiatives actually ship. For engineering: we’ll reduce the analyst support burden and enable AI innovation, not add bureaucratic overhead. For executives: measurable ROI, not faith-based initiatives.

What This Actually Looks Like

The practical implementation had four phases:

1. Establish the domain map. Get agreement on how the enterprise’s data landscape breaks down. This becomes the shared vocabulary.

2. Map use case data needs. For each priority initiative, trace through every data family it depends on. Be specific.

3. Identify gaps. Document the concrete data issues blocking each use case. Rate the severity for that specific initiative.

4. Shape initiatives. Aggregate the gaps, prioritize by business impact, and build focused governance initiatives that remediate the highest-value problems first.

We didn’t try to govern all data at once. We focused governance effort where it would unlock the most business value, then expanded systematically.

What AI-Ready Actually Means in Practice

Here’s where the rubber meets the road. “AI-ready data” isn’t a vague aspiration. It has specific, concrete requirements:

Structured and typed. Free text fields and semi-structured blobs don’t work for most ML models. You need defined schemas with consistent data types. A “price” field that’s sometimes a number, sometimes a string, sometimes includes currency symbols breaks automated pipelines.

Standardized identifiers across domains. This is the connectedness requirement. Every customer needs a consistent ID that links their transactions, their product views, their support interactions. Every product needs an ID that connects inventory levels to catalog details to sales history. Without this, you can’t build features that span domains.

Temporal consistency. AI models often need to understand sequences and time-based patterns. That requires timestamps in consistent formats (UTC, ISO 8601), clear “created_at” and “updated_at” fields, and the ability to reconstruct state at any point in time.

Clear lineage and transformation logic. For any derived field or calculated metric, you need to know where it came from and how it was computed. This supports both model debugging and regulatory requirements around explainability.

Schema contracts between producers and consumers. When a team publishes data, downstream consumers need guarantees about structure, freshness, and completeness. Breaking changes need versioning. This is what enables teams to build on each other’s data products.

These aren’t theoretical nice-to-haves. These are the requirements that kept showing up across every AI and ML use case we analyzed. And they map directly to specific governance practices: field standardization, entity resolution, metadata management, data contracts.

The Organizational Model That Made It Work

Here’s the structure that worked: a federated model with clear partnership between central governance and domain owners.

A small central governance team (not a bureaucracy) sets standards and provides enabling resources. But each business domain has an owner. Someone accountable for defining strategy, ensuring funding, and delivering reusable datasets for their domain.

These domain owners aren’t in engineering. They’re product or business leaders who understand the domain and have skin in the game. They partner with the governance team to apply enterprise standards while maintaining domain execution control.

Application teams handle the technical implementation. They build pipelines, apply schema standards, and ensure datasets meet requirements. But they’re not confused about why they’re doing this work. It’s directly connected to AI and analytics capabilities they need to deliver.

The key is that governance serves the domain owners, and domain owners serve the use cases. Everyone’s incentives align around enabling AI capabilities, not enforcing policies.

Why AI Readiness Changed the Conversation

Positioning this work as “AI readiness” rather than traditional data governance opened doors that would normally stay closed.

Engineers get excited about enabling AI capabilities. They understand intuitively that machine learning requires structured, typed, connected data. They know models can’t learn from free text fields and inconsistent enumerations. They see why entity resolution across domains matters for building features. The connection between rigorous data practices and shipping AI products is obvious in a way that “data quality” never is.

Executives understand AI as competitive advantage. When you frame data governance as “establishing the structured, connectable data foundation we need to build AI capabilities,” that’s strategic. When you frame it as “improving data quality,” that’s IT overhead.

The actual work is the same. Standardizing field formats, establishing consistent identifiers, documenting transformations, creating clear schemas, building API contracts. But the framing determines whether people engage or ignore you.

And here’s what really mattered: we could point to specific AI capabilities that competitors were building and say “we can’t do that because our data isn’t structured this way” or “we can’t connect these domains reliably.” That creates urgency in a way that abstract data quality metrics never do.

What We Learned

Start small, prove value fast. We picked two use cases for the first wave. This gave us concrete wins to build momentum and learn what actually worked before scaling.

Cross-domain connectivity is where the value is. Individual datasets being “clean” matters less than datasets being connectable. Standardized IDs, consistent schemas, and clear relationships between domains unlock more value than perfect completeness in any single domain.

Business impact trumps technical perfection. We prioritized data issues by how much AI capability they unlocked, not by how “bad” they were technically. A minor schema inconsistency blocking a high-value ML model beats a major quality issue in unused data.

Governance without enforcement is suggestion. We built compliance scorecards, audit processes, and consequences for non-compliance. Friendly but firm. The expectation that contributions to shared data platforms meet structure and connectivity standards isn’t optional.

Domain-based thinking is hard. Helping application owners shift from “what does my application do” to “what business capability do I own” takes sustained effort. It’s a mindset change, not just an org chart change.

Terminology matters. We found “AI Readiness” or “Data Enablement” landed better with executives than “Data Governance.” The work is the same, but language that emphasizes competitive capability over control gets less resistance.

The Pattern That Emerges

If you step back, there’s a broader pattern here about how to drive organizational change around data:

1. Anchor to business outcomes people actually care about (AI capabilities, competitive advantage)

2. Make the connection between data structure and those outcomes explicit and immediate

3. Prioritize ruthlessly based on what enables cross-domain connectivity and AI capabilities

4. Build partnerships between central standards and distributed execution

5. Prove value in tight iterations before scaling

This isn’t really about data governance. It’s about building the structured, connectable data foundation that modern AI and analytics capabilities require.

Most governance programs fail because they try to be comprehensive from day one. They want perfect metadata, complete lineage, and pristine quality across all data before anyone uses it. That never happens.

The alternative is to be surgical. Find the AI capabilities that matter most for business outcomes. Identify the specific structure and connectivity requirements blocking those capabilities. Fix those problems. Prove value. Expand systematically. Repeat.

Your governance program succeeds when it becomes invisible. When teams contribute structured, well-connected data to shared platforms because it’s the path of least resistance to shipping AI-powered initiatives, not because compliance says they have to.

The goal isn’t perfect data governance. The goal is data that AI systems can actually consume, connect, and learn from at scale. Everything else is just scaffolding to get there.

I was approaching this the wrong way.

The problem wasn’t that I misunderstood the goal. The problem was that I was solving for the wrong type of failure mode. I was thinking about how humans experience messy documentation when I should have been thinking about how machines experience it.

The consumer of unstructured data is shifting from humans to machines, and they fail differently.

When a human reads two contradictory internal documents, they use judgment. They know the 2019 policy doc is probably stale. They remember that Ben’s team does things differently than Susan’s. They can tell when something doesn’t add up. The cost of messy documentation in a human world is inefficiency. People waste their time finding the right source.

When an AI agent encounters the same contradiction, it treats both documents as equally valid. It doesn’t know which is current, has no institutional memory about team differences, and can’t detect inconsistencies the way humans can. The cost shifts from inefficiency to confident automation of errors. The agent doesn’t get confused; it gets wrong.

This matters because agents are being deployed into environments where unstructured data has never been properly organized. Most enterprises spent decades accumulating documents, wikis, email threads, Slack chats, meeting recordings, and PDFs with minimal governance. While historically annoying, the ROI for organizing that content never penciled before. Why would it now?

Why I stopped planning document cleanup

Content curation means reorganizing documents: deduplicating, building taxonomies, standardizing formats, migrating to unified platforms. It’s what most “AI readiness” initiatives are doing. It’s what I was planning to do.

But the problems kept stacking up in my planning:

It’s expensive. Requires dedicated headcount, consultant engagements, content migration projects. You’re paying people to reorganize documents that are probably fine where they are.

It’s fragile. Tools change constantly. SharePoint becomes Confluence becomes Notion. File formats evolve. Each platform shift breaks the curation work. The half-life of organizational content infrastructure is… maybe 3-5 years?

It will be too slow to help AI. RAG architectures, context windows, and retrieval strategies are evolving fast. What you optimize for today’s chunking logic may be irrelevant in six months when context windows hit 10M tokens.

Nobody does it even when they should. Most organizations had decades to organize their content before AI agents arrived. They didn’t, because the cost-benefit wasn’t there. The existence of document management tools doesn’t mean organizations use them well.

What I suggest instead

Once I understood the new failure mode for agents, I stopped trying to reorganize content. Epistemic governance accepts that organizational content will stay messy. It adds a governance layer on top without reorganizing the underlying documents.

The analogy is DNS, the Domain Name System, which powers the web. DNS doesn’t reorganize the internet or deduplicate websites. It simply provides a lightweight registry that maps domain names to IP addresses and includes mechanisms for resolving conflicts (TTL expiration, authoritative nameservers).

Epistemic governance for unstructured data works the same way. It has three components that work together.

First is the authority registry. This records who knows what. For each knowledge domain and subdomain, you capture who the recognized expert is, what the canonical source document is, what documents it supersedes, and when it was last validated. This is a small, maintained data structure, not a reorganization of documents themselves. The documents stay where they are. You’re just making the informal authority network explicit and machine-queryable.

An example entry: “For wholesale vehicle price adjustments, Jane Smith (Senior Pricing Analyst) is the authority. The canonical source is wholesale-adj-v3.docx on SharePoint, last validated Feb 2025. It supersedes the 2022 Confluence page and the 2023 draft that was never finalized.”

Don’t worry, the registry doesn’t need to cover everything. Start with 5-10 subdomains in a single knowledge area. Each entry comes from a 90-minute session with the domain expert where you identify the canonical sources, document what they supersede, and set a validation cadence.

Second is the contradiction log. This tracks known conflicts between sources. When two sources are known to conflict, you record what specifically contradicts (precise claims, not vague descriptions), who reviewed it, and what the resolution is.

Contradictions come in types:

• Resolved conflicts have a clear answer: one source is right, the other is wrong. The log records “Use exponential depreciation curve from Source B. Source A’s linear model was replaced in Q3 2024.”

• Accepted conflicts, however, are intentional. Both sources are correct for different contexts. Wholesale and retail pricing models legitimately use different methods. The log records “Present both approaches and ask user which context applies.”

• Under review means identified but not yet adjudicated. The log captures that the conflict exists so agents can caveat their responses until it’s resolved.

Third are the resolution rules. These are the policies agents follow when encountering ambiguity. Start with five simple rules that handle most scenarios:

1. If the contradiction log has an explicit resolution for this conflict, follow it. This overrides everything else.

2. When sources conflict and one is registered as canonical, defer to it. Exception: if validation is stale (over 12 months), flag for re-validation.

3. If a question falls outside registered subdomains, answer with available information but caveat that the topic isn’t covered by the governance system. Log the gap.

4. If canonical source validation is stale, use it anyway (stale governance beats none) but caveat the staleness and flag for review.

5. When contradiction is marked as accepted (intentional), present both approaches and ask user which context applies.

Why this compounds

The authority registry and contradiction log become more valuable over time.

Each new domain entry makes the system more useful through network effects. An agent that can handle wholesale pricing conflicts becomes more capable when retail pricing gets added.

Once you have a registry, agents encountering unregistered subdomains generate demand signals for where governance should expand next. Your gaps become visible through conflict detection.

The last_validated date creates pressure to keep expertise fresh. When a canonical source goes stale, the system flags it. This validation forcing function is better than relying on document modification timestamps because currency is about expert validation, not file system events.

The registry survives platform migrations. When your organization inevitably moves from Confluence to Notion (Or back. Again.), the authority records stay valid. You just update the URLs in the canonical_source field. Compare this to soul-crushing curation work that has to be redone with each tool change. The governance layer is portable across tools.

Let’s Compare

The two approaches aren’t mutually exclusive. You can do both. But they have different cost profiles, sustainability characteristics, and failure modes. Curation is expensive and fragile but visible (executives can see reorganized folders). Epistemic governance is cheaper and more durable but requires accepting that metadata about content matters more than reorganization of content.

Wait, what about usage signals?

I hear some of you already asking why we aren’t just crowdsourcing the right data as many tools today recommend. Usage data is valuable but not as governance input. Instead it is valuable as triage input. Which documents agents actually retrieve, how often, and in what contexts does matter, but that isn’t trust.

High retrieval frequency on an unregistered subdomain also tells you where to register authority next. Conflicts discovered through agent use will tell you what to add to the contradiction log. Therefore, usage patterns are diagnostic: they tell you where governance attention is needed, not which sources are authoritative.

This distinction matters. If you let usage signals directly determine authority (the most-retrieved document is the best), you’ve removed the expert from the loop. That collapses the system back to the same problem it was designed to solve: machines deciding what machines should trust.

Usage data tells you where to apply expert judgment. It doesn’t replace expert judgment.

What changed my thinking

Three realizations shifted my approach from content curation to epistemic governance.

First was understanding that agents experience document chaos differently than humans do. Humans get frustrated and inefficient. Agents get confidently wrong. This changes the economics of governance because the cost of ungoverned data shifted from friction to automation risk. Once I saw this, I couldn’t unsee it.

Second was the DNS analogy. I was thinking about knowledge governance as content reorganization because that’s how most data governance literature frames it: schemas, taxonomies, data lakes. But DNS doesn’t reorganize the internet. It provides a lightweight registry layer. Dave McComb’s Software Wasteland touches on this with knowledge graphs as governance infrastructure, but the analogy to DNS as a minimal viable registry clarified something for me. You can govern without reorganizing.

Third was recognizing that usage data tells you where to look, not what to trust. I initially thought about letting usage signals become authority decisions. Most-retrieved document becomes canonical, right? But that conflates popularity with correctness (wasn’t true in high school, isn’t true today). That works in consumer web contexts (PageRank, collaborative filtering) but breaks in enterprise contexts where popularity and correctness diverge, especially when incentives favor document creation over document maintenance. Usage data is triage input. It tells you where to apply expert judgment. It doesn’t replace expert judgment.

I was wrong about AI readiness because I was solving for retrieval when I should have been solving for trust. The documents don’t need to be findable in a cleaner folder structure. They need to carry signals about authority, currency, and conflict resolution that agents can act on.

The work isn’t reorganizing content. It’s making the informal authority networks in your organization explicit and machine-queryable. That’s a different kind of governance, with different economics and different durability characteristics. It compounds instead of decaying.

Further reading

Martin Kleppmann, Designing Data-Intensive Applications: Chapters 5 and 9 on eventual consistency and conflict resolution. The concepts translate directly from distributed systems to unstructured data governance.

Dave McComb, Software Wasteland: Makes the case that we over-invest in organizing data and under-invest in making meaning explicit.

Andrew Ng, Data-Centric AI Resource Hub: The case for investing in data quality with human-in-the-loop processes rather than relying on model improvement alone.

The Articles of Confederation were America’s first operating system. They were a reasonable design, born from a reasonable fear: the colonies had just escaped centralized authority and they weren’t about to recreate it. So the Articles gave each state maximum autonomy. No executive branch. No federal courts. No power to tax. Congress could request things from states. It could not compel them.

It didn’t work. Autonomy without coordination produced fragmentation, not freedom. States issued their own currencies. Trade disputes went unresolved. Shared problems like defense, debt, and interstate commerce festered because no one had the authority to address them.

The Constitution wasn’t the founders’ first idea. It was their correction.

I’ve been thinking about this because I’ve spent a lot of my career in technology watching organizations try to transform how they build and deliver software. Most of these transformations follow the same arc: someone declares that the current way of working is broken, publishes a new operating model, and expects adoption. Declaration to Constitution in a single step. They almost always fail, and usually for the same reason the Articles failed. Nobody did the work of understanding why the current state exists and what legitimate needs it serves.

-----

In most large technology organizations, teams own domains. They own backlogs. They own their release cadences and deployment rituals. Coordination between teams happens through negotiation (meetings, Slack threads, escalations) rather than through structure. Shared concerns go unaddressed because no single team has the authority or incentive to solve them.

That’s the Articles of Confederation. And like the Articles, it didn’t emerge from stupidity. It emerged from trauma. At some point, a top-down mandate failed these teams. Someone centralized decision-making, removed autonomy, and created bottlenecks. Teams responded by claiming sovereignty over their territory. They built walls out of self-preservation, not selfishness.

When you frame the current state as the Articles rather than as dysfunction, it changes the conversation. The Articles were a rational response to a real problem. What comes next isn’t revolution. It’s a constitutional convention: a correction informed by experience, not imposed by ideology.

-----

The founding generation produced a stack of documents, and each one did something the others couldn’t. I think this sequence is more useful as a change management framework than most of what I’ve seen in the Agile or transformation literature.

The Declaration of Independence was philosophy. It didn’t describe how the new government would work. It made the case that the old arrangement was untenable, cataloging specific grievances against a system that had become unresponsive to the people it was supposed to serve. If you’re transforming a delivery organization, your Declaration makes the pain of the status quo specific and evidence-based. Not “we need to be more agile,” which is a bumper sticker. Something more like: here are the seven ways our current model fails the people who depend on what we build.

The Constitution was architecture. Structure, jurisdiction, and separation of powers. Who owns what. How authority flows. What decisions get made at which level. The founders’ core design insight was federalism, a division of sovereignty where certain powers belong to the national government and everything else is reserved to the states. In a delivery organization, this maps onto the tension between enterprise standards and team-level autonomy. Security requirements, data contracts, API standards, platform decisions: federal. Implementation patterns, tooling choices, internal rituals: state. Getting this boundary wrong in either direction was the exact failure mode the founders were designing against.

The Bill of Rights was a set of guarantees. The Constitution alone wasn’t enough for ratification. People needed explicit assurances that the new centralized structure wouldn’t recreate the problems of the old one. In an engineering organization, this means telling teams what they’re entitled to under the new model (clear specifications before work begins, autonomy within defined boundaries, and access to shared platforms) and what they’re protected from (mid-sprint scope changes, accountability without authority, and ambiguous ownership).

The Federalist Papers were persuasion. Hamilton, Madison, and Jay didn’t publish the Constitution and wait for applause. They wrote 85 essays, each one arguing for a specific design decision to a skeptical public. Why this structure? Why these tradeoffs? Why not the alternatives? If you’re transforming a delivery organization and you haven’t written the equivalent of the Federalist Papers, standalone arguments for each controversial design choice, you’re asking people to adopt a system they don’t understand.

-----

The part of this history that sticks with me most is the opposition.

The Anti-Federalists, Patrick Henry, George Mason, and Mercy Otis Warren, argued that the Constitution concentrated too much power. That it would erode local responsiveness. That the cure was worse than the disease. They made their case publicly, in essays and speeches that matched the Federalists point for point. They lost the ratification debate, but they won a concession that mattered more: the Bill of Rights exists because the Anti-Federalists demanded it. The Constitution is a better document because people who believed it was dangerous forced its authors to prove otherwise.

Every transformation has Anti-Federalists. They argue that your new team model destroys hard-won domain expertise. That your new process adds overhead. That centralizing ownership dilutes accountability rather than strengthening it. These are legitimate structural concerns, the same ones the historical Anti-Federalists raised, and they deserve the same treatment: engagement, honest concession where warranted, and design changes where the evidence supports it.

I’ve come to think the best thing a transformation leader can do is publish their own Anti-Federalist Papers alongside the Federalist ones. Steelman the strongest objections to your own design, then address them. It shows the new model has been tested against its failure modes. And it takes the air out of opposition by acknowledging the concerns before they harden into resistance.

-----

Thinking more about this comparison, a few more constitutional mechanisms translate directly:

The Supremacy Clause (Article VI) establishes that federal law supersedes state law when they conflict. Every delivery organization needs an equivalent. When a team’s local optimization conflicts with an enterprise requirement, what wins? If you don’t answer this explicitly, you’ll answer it through escalation which is slower and more corrosive.

Judicial review, established by Marbury v. Madison in 1803, addresses who arbitrates disputes. When two teams disagree about ownership of a shared domain, or a specification is ambiguous, who interprets the Constitution? The useful insight from the courts is that the arbiter should be separate from both those who write the rules and those who execute them.

The amendment process (Article V) might matter most. The Constitution was designed to be changed, but not easily. Supermajorities are required. The system evolves deliberately rather than reactively. Your operating model should define its own amendment process: who proposes changes, what evidence is required, what threshold triggers adoption. Rigidity breaks and instability exhausts. Article V sits between those two failure modes.

-----

There is one question this metaphor keeps forcing on me…

Every constitutional system exists to serve someone. In government, the whole structure exists for the citizen. In a technology organization, who’s the citizen? The end user? The internal team consuming a shared platform? The business stakeholder?

If the citizen is the end user, your Constitution optimizes for delivery speed and quality to market. If it’s the internal consumer, you optimize for composability and reliability. If it’s both, you need something like dual sovereignty, which is what federalism was built to handle.

The American founding was messy, Ii was argumentative, and It was built on the admission that the first attempt didn’t work. Twelve years of operating under an inadequate system gave the founders the experience to design a better one. As the country marks 250 years since the Declaration, I think the more interesting anniversary is still two years out. The document that actually governs, the Constitution, came from the willingness to admit that independence alone wasn’t enough. You also need architecture and a thoughtful operating model.

Same thing is true for how we build software. Declaring the old way broken is necessary, but that’s 1776. The harder work is Philadelphia, 1787.

Last Friday, our friend and cube-mate Spider Rico passed away. Much like his namesake, he was a fighter. However our Spider Rico lost his battle not to the Italian Stallion, but instead to the mortal coil.

Already, we are feeling the pain of loss as we come to work and walk past his empty fishbowl. Where once a happy little fish slumbered on his plastic plant and anxiously anticipated a daily ration of food pellets, now there is only a sticker of a fish affixed to his bowl in memoriam. I would caution you not to see that as a statement of our ability or willingness to keep fish alive, but instead as a symbol of how irreplaceable Spider Rico will always be.

Even in death, Spider Rico had one last lesson for all of us. He gave us yet another reminder that life is fleeting. Let his passing serve as the catalyst to restore work/life balance in your own life lest we come to work one Monday morning and find you slumped over your keyboard. Make time for your family and friends; Clarity will still be here tomorrow.

Upon finding Spider Rico, a cry of outrage arose from his admirers. We appreciate everyone’s concern, but after a complete criminal investigation, we can safely exonerate any suspects. The coroner ruled this case as expiration from natural causes. No foul play was involved, and we should no longer persecute the innocent (Tim).

The funeral was held Monday morning when Spider Rico was given a burial at sea in the 5^th floor handicapped bathroom. Spider Rico leaves behind a single relative, his sibling Thunderlips. In lieu of flowers, feel free to deposit donations in the Curse Bowl for his ongoing care and support.

If you are overcome with grief and need to talk to someone about dealing with this loss, please remember our Employee Assistance Program.