In my past 20 or 30 years of work in Enterprise software design ..about 20% of what I do is something called information architecture which as you may know is.. naming things, formal domain entity schemas, data layer name spaces, business dictionaries, thesauruses, site maps, table of contents, navigation systems, semantic heuristics, ontologies, taxonomies and a lot of information retrieval (IR) science. 

I read papers on this stuff and follow a bunch of experts, but 90% of it is hand waving and smoke blowing because of the immensely n-dimensional,  combinatorially explosive nature of organizational semantics.

So here's my current real world experience.

This stuff is a joy to do when you're working with Claude and you've got a bounded code base and content library .. and then you decide that a concept like 'retriever' that affects a whole bunch of naming has to change to a slightly orthogonal concept like 'advisor'.

 Claude will go out into the codebase and change everything that is affected by this mental model shift including code,  settings, file names, folder names, GitHub repos, and all sorts of documentation.

In the process Claude will break some dependencies and the software will no longer work because naming is incredibly entrenched and always turns into a big mud ball, even on modest scale...  but here's what's different... after Claude breaks things it can fix things pretty quick. 

So that's a joy... name space refinement on steroids.

Evolving a efficient naming spec is very possible with a small team working with one agentic framework and one code / content base, but scaling this to a sophisticated semantic architecture at the organizational level is a lot harder because there's so many operational,  professional, linguistic, political, cultural, etc. forces in play.

 But we have to try! 

Can we achieve a usable ontology and semantic layer inside a greenfield project? Sort of, but every page of content that we import from existing corporate and published sources tends to work against us and ultimately require long conference calls with many different disciplines to work out the representational and linguistic issues. 

With the AI and focused domains we can slowly help fix this at the organization level. 

 Here's  more background from me, prompting perplexity.

------

The Definition Problem Nobody Owns

When crafting a semantic layer for complex projects, products or organizations, the hardest part isn't choosing between DBT, Cube, or Looker — it's getting finance, product, and engineering to agree on what "churn" or "revenue" actually means .

 In practice, three departments often define the same metric differently, and deploying an AI or reporting agent returns three different answers depending on which table it queries first.

 This is a human coordination problem that requires sustained organizational will, not just engineering effort.

Definitions Suggested, Not Enforced

Many teams build metric catalogs and shared documentation that look aligned on paper but behave inconsistently in practice . Analysts still write custom queries, dashboards still redefine logic, and spreadsheets still adjust numbers downstream. The semantic layer becomes a passive reference artifact rather than an active enforcement system .

Structural Failure Modes

Semantic layer initiatives fail primarily because of technology-centric thinking, inadequate data quality preparation, and missing business context . Here's a breakdown of the core failure modes:

Treated as a One-Time Project

Meaning is not static — businesses evolve, products pivot, and regulations change. Organizations that approach semantic alignment as a cleanup effort or a migration project define metrics, align teams, and then move on . Without continuous maintenance, versioning, and active stewardship, the layer rots relative to actual business reality .

Institutional Knowledge Erosion

In complex organizations, column names that seem cryptic are often artifacts of transformations designed for specific downstream needs that were never documented . Fields get renamed, merged, or derived across pipeline stages, and the reasoning leaves the organization along with the engineers who made the decisions. By the time a new consumer needs to make sense of the data, the path from raw source to current schema is opaque .

The Governance Gap in AI-Era Systems

Traditional semantic layers were built for dashboards and human-led analysis — they document definitions instead of enforcing them. They apply governance after queries are generated, not while AI is reasoning through data . As AI agents become primary consumers of semantic models rather than human analysts, this passive approach compounds failure .

The core insight is this: a semantic layer is organizational infrastructure, not a software feature or an engineering problem. It requires the same planning rigor as a core production system, clear ownership models, change management processes, and continuous investment — not a one-time deployment.