All episodes
S1 · Ep 3Knowledge Graphs

The Vocabulary Problem — what 'context' actually means

Alan Morrison has spent two decades watching technical vocabularies get coined, hyped by vendors, and hollowed out — knowledge graphs, grounding, and now "context." Drawing on 20 years running PwC's Technology Forecast think tank, he argues the vocabulary problem in enterprise AI isn't a communication failure but an architectural one: when words stop meaning anything, architecture follows marketing and teams hold the repair bill for years. He makes the case for data-centric over application-centric, why incumbents stay stuck, and the smallest credible first step toward a knowledge-graph layer.

Alan MorrisonBio ↓
Independent analyst & researcher · graphrag.info
The speaker

Alan Morrison

Independent analyst & researcher · graphrag.info

A longtime analyst, project manager, writer, advisor, and podcaster focused on advanced data technologies and emerging IT. For 20 years at PwC's R&D and innovation think tanks he identified emerging technologies on the cusp of adoption, assessed their business impact, and advised PwC's clients on innovation strategy. Before PwC he was a semiconductor-industry market analyst and forecaster, a retail site-location analyst, and a US Navy intelligence analyst, Russian linguist, and aircrewman.

Episode evaluation

What to do with this episode

Four clear reads — who should act, and how urgently.

01For buildersTEST

Run a parallel architecture

Stand up a knowledge-graph track alongside your existing stack on one painful use case — the way Montefiore did with sepsis prediction — and prove it before you scale.

02For data & AI leadsUSE

Enrich data upstream, not prompts down

Trustworthy agent outputs come from knowledge-enriched data captured upstream, not from patching the context window. Make data quality the project, not the afterthought.

03For enterprise buyersWATCH

Hire for hype immunity

Leadership that can't smell BS takes the whole org on a wasteful spending cycle. Make resistance to hype an explicit leadership and board-level test.

04Bottom lineSHIP

Commit to building, not buying

The enterprises that win commit over generations to hands-on building in small, consistent steps. No product on the market solves this for you.

Show notes

We discuss

  • 01Why "context" is the latest word to get coined, hyped, and hollowed out — and the pattern it shares with knowledge graphs and grounding.
  • 02Application-centric vs data-centric architecture (Dave McComb's Software Wasteland) — and why incumbents keep one foot in the past.
  • 03Why enterprises ignored ontologies and taxonomies for decades, and how knowledge management, content management, and BI can finally become one team.
  • 04Foxes vs hedgehogs — who actually drives transformation on the buyer side, and why informal networks beat the org chart.
  • 05A mortgage-collection-call scoring case — why a million-token context window and ten prompts isn't the same as enriched, trustworthy data.
  • 06Why this is the biggest change-management challenge since wartime manufacturing, and the one thing Alan would change tomorrow.
Reference

Transcript

VivekWhen did you realize the problem wasn't the model?

AlanIt depends what kind of model you mean. My view was shaped by years of research on databases and query. Go back to the 2010s and the hot topic was big data — commodity hardware piling up data lakes. But the data lakes weren't helping much. There's a kind of modeling that lives under the header of ontologies, taxonomies, and controlled vocabularies. Librarians have used it for decades, but enterprises stayed ignorant of it, because they were committed to structured data, relational databases, and SQL. Those are fine — but that data-modeling approach doesn't scale to big-data environments. That's where ontologies are used to create FAIR data: whatever the type of data, you can bring it together into one big graph.

VivekWhy is migrating between AI systems so much harder than migrating from Salesforce to Microsoft Dynamics? In the AI context it's not a JSON file you can export and import.

AlanBecause we've had this fragmentation for so long, and there hasn't been a good-faith effort by enough companies to address it. There's a wonderful book, Software Wasteland by Dave McComb, about application-centric versus data-centric. The application-centric approach is the fragmented one: a lot of logic trapped in application code, recreated by developers over and over, with instance data duplicated everywhere — data warehouses, lakehouses, data lakes. The graph approach exists to address that fragmentation. It's not an easy fix, and it requires commitment.

AlanMost large incumbents are committed to older architecture, because they grew up in the application-centric era, before AI really took hold. Their claims are about two things: real innovations they're justifiably proud of, and the old stuff they still want to keep selling. They've got one foot in the past and one foot in the present. Companies can't afford to commit to whatever their favorite software vendors want them to do anymore. They have to take an independent route to transformation — and it's not just technological. These departments have to be transformed too.

AlanThe goal isn't to eliminate language models, large or small — it's to use them together with a knowledge-graph approach. You enrich the data upstream and capture quality data upstream, so that what you feed the AI is trustworthy when it comes out the other end. Current AI is a black box; it needs quality input to produce trustworthy output. The only way to get that is to take ownership of the work stream.

AlanWhat knowledge is, is conceptual abstractions. You want agents to have access to those abstraction layers, so they understand not just the concept at hand but the whole field it belongs to and its different meanings in each context. Take the ContextOps podcast — there are all these domains, and different layers of abstraction you're building. If you take an ontological approach — start with controlled vocabularies and taxonomies, then build the ontology — the machine gets layers of abstraction it can navigate, so it interprets correctly what the data means in a particular context.

VivekIs this just how markets form — concepts get named, overextended, and then it takes time to settle into a real definition? Or is something about this specific cycle different, which makes the vocabulary drift more harmful than usual?

AlanSomething's different now. Go back 20 to 25 years to Nick Carr's IT Doesn't Matter. His argument was that IT is all commoditized — companies don't need to worry about the technology, just commit to your favored vendor and they'll steer you right. That might have been okay for a while. So companies subscribed to suites, then to software as a service — large enterprises now have hundreds of thousands of SaaS subscriptions, all perpetuating the older architecture. There's a ton of noise from vendors struggling to hold market share, all making AI claims. You have to be a contrarian to sift through it and realize there isn't much trusted signal out there.

VivekYou've talked about foxes and hedgehogs. When there's this much noise, how should vendors actually work with the buying committee on the other side?

AlanAt PwC — hundreds of thousands of people globally — the formal org chart wasn't how you got things done. If you needed someone's help, you worked the informal network. I used internal social media to find people curious about the same things, and we piloted knowledge-graph projects that way. The caveat: a few pockets of innovation don't get you a firm-wide result. Most companies experimenting with this adopt it in small pockets. The hedgehogs are good at keeping the lights on, keeping the established business running — they're important. But the foxes are the ones who have to lead the effort to adopt AI the right way.

VivekWe had a similar experience at CogniSwitch. The POC worked, and the person who owned data management was aligned in principle. But they needed someone to sign off on the knowledge-curation part — a true guardian of the source of knowledge. The business buyer said: not us. We don't have the time, we don't even have a knowledge function — we barely have a data function. Standing one up for something they didn't yet fully understand felt like a bet they weren't ready to take, so they went with a different deployment.

VivekTake a product manager told to score reps on mortgage-collection calls — short calls, ten or fifteen minutes. The temptation is: we have a million-token context window now, so just drop the call in and ask ten questions. Why does that simple prompt-based approach on unstructured data fall short?

AlanLarge language models are useful for certain things — it's about using the tools the right way, and I've been on that learning journey myself. I found I was wasting a lot of time with the language model, and my approach has changed significantly over the months. Companies face the same education: decide how to use the tools at hand in the best way, and make sure the tooling available now doesn't get in the way of the longer-term strategy. Not all of these tools are useful for all use cases — you have to be judicious, and people shouldn't waste time using a tool for a purpose it was never intended for.

AlanLeadership really needs to be immune to the hype. The board ought to insist on it. Whoever gets appointed should be savvy about not being subject to hype, and not putting the organization through a spending cycle that's just wasteful. Companies aren't going to survive and thrive unless leadership is savvy about this.

VivekOne thing you'd change about how enterprises do this — and it actually happens tomorrow. What is it?

AlanYou have to stop buying into the notion that the stuff you're purchasing will solve your problems. You need a much larger commitment to being hands-on and building, rather than just buying the solution. If you have enthusiastic people building in a small way, and you keep the company on that track, it works — but not immediately. It can't just be one person's idea; everyone has to be committed. It's a bigger management challenge than companies have faced in a long time — maybe since before World War II, when they had to retool for wartime manufacturing. People don't really realize the nature of the challenge.

Operationalize

Take this episode to your AI

Open this episode in your assistant with the summary, key points, and a link to the full transcript — then put the insights to work in your own context.

Opens in a new tab · shares only this episode's public transcript link

Keep listening
S1 · Ep 4Melli Annamalai

A graph is one tool, not the destination

Melli Annamalai has spent 27 years at Oracle watching technology waves crest and break — multimedia retrieval, the semantic web, big data, property-graph analytics, and now knowledge graphs for AI. As the Distinguished Product Manager who leads graph technologies there, she makes an argument you rarely hear from a database vendor: a knowledge graph is one tool in the kit, not the destination. She traces why semantic-web tech stalled for two decades — a steep learning curve, a custom RDF/OWL/SPARQL ecosystem, and the year-and-a-half payback that senior management wouldn't fund — why AI finally gave enterprises a reason to invest, and where these projects still quietly fail: over-engineering everything into a graph, tuning and tooling gaps, and the security officer who shuts it all down. Along the way, a working definition of "ontology" for non-technical buyers, natural language as the new query language, and Oracle's converged-database bet to collapse the graph, vector, and agent layers into the place the data already lives.

Knowledge GraphsView episode
S1 · Ep 2Tony Seale

Discover your ontological core

Tony Seale spent two decades stitching together siloed data inside investment banks — Lehman, Deutsche Bank, UBS — until he concluded the hard part was never the model, it was the data. Now widely followed as "the knowledge graph guy," he makes a precise argument: a large language model is rented intelligence you don't own, while the ontology and knowledge graph you build are the durable IP that stays inside your organization. He walks through the neuro-symbolic loop — why LLMs are continuous and knowledge graphs discrete, and why you cycle between them rather than pick one — coins Seale's Law on how marketing hollows out a word's meaning, and warns that companies that don't consolidate their "ontological core" will watch their advantage quietly leak out. Along the way: semantic data products and the DPROD standard, why true open standards (schema.org, W3C) beat vendor "open," and why the agentic web arriving next makes getting your data estate in order the only move that counts.

Neuro-Symbolic AIView episode
S1 · Ep 1Elliott Risch

Own your meaning, or rent it

A CTO has a 2-million-token context window and thousands of recorded cancer-care calls. The plan: pipe them in, ask for provider performance, done. Elliott Risch — who runs R&D on semantic AI at Enterprise Knowledge and came to it through mathematical logic, not engineering — walks through where that holds and where it quietly stops flagging the contradictions that matter, until someone has to stand in court and say the computer made a mistake. He separates inductive systems (LLMs that guess the next token) from deductive ones (rules that must hold every time), and makes the case for owning the meaning of your company instead of renting it.

Semantic LayerView episode
Go deeper

Further reading