Job-Contextual Semantic Modeling: The Need for a New Category Beyond Catalogs, Glossaries, and Semantic Layers

Every enterprise I have worked with already owns a business glossary, a data catalog, and increasingly a semantic layer feeding BI tools and agents. Ask any of them what "Active Customer" means, and the answer comes back instantly, governed, and current.

Ask why that definition looks the way it does, or who will need to know when it changes next quarter, and every one of these systems goes silent.

A data team tracing why a business definition changed, without records to explain the decision.

A semantic layer tells you what a term means right now. It has never told you why — or who decided, or what job that decision served.

That silence used to be survivable. Agentic AI makes it expensive.

The Category Everyone Is Building, and the Gap Nobody Named

Around 2016 at coffee retailer, I orchestrated this stack in real time. First came the data catalog, indexing tables and columns. Then a business glossary bolted next to it, translating column names into terms a human could read. Then governance tooling arrived to police both, enforcing who could change a definition and when.

Ontology and taxonomy tools followed — Protégé, OWL — trying to formalize relationships with academic rigor. That lineage stayed mostly inside research labs and life sciences, because the authoring cost was too high for a retail or SaaS business to absorb at scale.

Meanwhile, Tableau, Power BI, and MicroStrategy each built proprietary semantic layers, stacking dimensions and facts, and called the result "semantic modeling." Then graph databases and RAG pipelines gave the same word a third, unrelated meaning — oriented around vector similarity, not governed business definitions.

None of this happened in a vacuum. Domain-Driven Design kept its own discipline alive on the software side, through bounded contexts enforced in code. dbt and Dagster turned data pipelines into testable, versioned assets. Both lineages stayed separated from the glossary and catalog world, often in the same building, sometimes on the same floor.

Every one of these tools solved something real. Stack them together, and you get five different definitions of "semantic," a business glossary a third of the company ignores, and a catalog that answers "what" perfectly while staying mute on "why."

The modern semantic stack grew in layers: catalogs, glossaries, governance, BI models, ontologies, graphs, and code-first domains.

Why Agentic AI Turns a Known Gap Into a Production Problem

Before agents, a human sat between a stale definition and a bad decision. An analyst pulling a report noticed a number looked wrong, asked a colleague, and got the missing context verbally — "that changed after the Q2 campaign, finance never got the memo." The correction happened in a hallway or a Slack thread, invisible to any system, and it worked well enough because a person caught the drift before it caused damage.

An agent does not ask a colleague. It reads the glossary entry in front of it, treats it as complete, and commits.

Agents do not become unreliable when a definition is stale. They become confidently wrong, at production speed, before anyone notices.

This is the exact failure mode I described from the identity side in Domain Modeling for Agentic AI: an agent acts only as intelligently as the model of the world it operates within. That post assumed the domain model, once defined, stays stable enough for an agent to trust. In practice, the model itself keeps moving — marketing redefines a segment threshold, a contract renewal process changes what "active" requires, a compliance rule tightens what "consented" means — and nothing in the stack captures that motion or the reasoning behind it.

Organizations are responding by buying more of the same category: bigger catalogs, richer knowledge graphs, more sophisticated RAG pipelines. The infrastructure improves. The agent still acts on a definition nobody remembered to update, because infrastructure was never the layer holding the missing piece.

What Every Layer in the Stack Actually Captures

Lay the five major categories side by side, and the pattern becomes obvious.

Layer	What it captures	What it misses
Data catalog	Tables, columns, lineage	Business rationale behind any given structure
Business glossary	Human-readable term definitions	Why a term changed, and what job it served
Ontology / knowledge graph	Formal relationships between concepts	Authoring cost too high for continuous business change
BI semantic layer	Governed dimensions and measures	Which of five competing "revenue" definitions is authoritative, and why
Knowledge graph / RAG	Retrieval context via similarity	Governed business meaning, as opposed to statistical proximity

No row owns the decision trail. No row connects a definition back to the business job that required it in the first place. That empty cell — not another catalog, not another glossary — is where the real opportunity sits.

Domain-Driven Design Gets Closest, and Still Falls Short

DDD deserves credit here. Bounded contexts assign explicit ownership of meaning, and aggregates enforce invariants in code rather than in documentation that drifts. A disciplined DDD team keeps code and business intent closer together than any catalog or glossary manages on its own.

But DDD's discipline lives in the codebase. It rarely reaches the glossary a data analyst queries or the catalog a governance team audits. The bounded context that decides what "customer" means to billing sits in a repository most data teams never open. The gap isn't a lack of rigor — it's that the rigor stays fenced off from the systems agents actually query.

A definition becomes durable only when it stays connected to the job and event that created it.

Job Context as the Missing Anchor

Here is the reframe I have been testing. A business term is not a fact about the world — it is a decision, made for a reason, on behalf of a specific job the business needed done. "Active Customer" means 90 days of purchase history because marketing needed a segment for a retention campaign. That job, not the number itself, is the durable thing. Jobs persist even when systems, teams, and thresholds change underneath them.

Map that job before writing a single glossary entry. Capture the event that triggered any change to a definition — a campaign launch, a compliance update, a renewal process redesign — before updating the catalog. Only then generate the glossary entry and catalog record, traceable back to the job and the event that produced it, instead of the other way around.

This does not replace your catalog, your glossary, or your semantic layer. It gives each of them a spine they currently lack: a record of why, tied to who needed it and when.

What Comes Next

Naming the gap is the easy part. Closing it requires a specific sequence — one that starts before any glossary entry gets written and ends somewhere most data teams have never looked for a semantic model.

I am building that sequence now, and the next post walks through it step by step.