Branded Content
Data lakes, data lakehouses, and S3 stored the mess. A knowledge graph is what finally explains it.
Written by: Matthew Halliday | Chief Product Officer, 4Minds
Updated 8:00 AM EST, November 2, 2026

Despite data management’s progress, unstructured data is still one huge, muddy puddle.
We’ve made incremental improvements over time, of course. From data warehouses that couldn’t store unstructured data at all, to data lakes that could store it, and then to data lakehouses that can both store and govern it.
But none of these approaches ever learned how to extract much value from unstructured data. So we stored it in S3 and planned to figure out later how to query it.
Well, that “later” is NOW.
AI can extract the value we’ve always known was hidden in unstructured data. It can read it. It can comprehend it, to an extent. It can even act on it.
But what AI absolutely cannot do on its own is understand how well select pieces of unstructured data agree with and reinforce each other as a connected surface across multiple nodes.
When I helped build Oracle Fusion, Oracle’s first cloud ERP environment that merged PeopleSoft and Oracle E-Business Suite into one product, it meant constructing a data pipeline that ran across 12,000 tables. Probably one of the largest data pipelines in the world at the time.
What kept the whole system honest was knowing how each piece connected to every other piece. ETLs and table mappings did that for us. We solved that problem for data warehouses.
But now data leaders face an even bigger, thornier challenge with AI. One that, before I joined 4Minds, made me feel like it was 2007 all over again but on a much, much bigger scale:
How to properly map all business data, from structured to unstructured, for AI and its agents.
Enter knowledge graphs!
While semantic search essentially asks, “What’s similar?” a knowledge graph asks, “What’s connected, and is it consistent?”
That’s why I say knowledge graphs are like the new Medallion Architecture for CDOs. They’re the only way AI agents can understand how enterprise data really connects and what those connections really mean.
It’s also why, once people get their hands on a knowledge graph, they become absolutely obsessed with it. And then they make a knowledge graph the linchpin of their AI strategy.
Ontology’s north star is always accuracy.
Yet the human-defined ontology required by most AI graph databases can’t deliver it. That ontology maps to your aspirational hopes for your data. You write the syntax of your ontology. Load your data into the graph database. And then your MLOps team spends the rest of their lives on the proverbial hamster wheel of cleaning, fixing, and trying to make sure data’s right.
But your data already reflects the reality of the world; you just need to map directly to it.
So what AI needs instead is “mathematical ontology”: cosine similarity that surfaces the mathematical relationships already baked into your vector space data and reveals the patterns and connections humans miss. With mathematical ontology, AI can infer things from your data. It can come up with rules for your data. It can deliver the accuracy you expect.
Frankly, I’ve never understood why most AI graph databases require human-defined ontology in the first place. We know AI is built purely on math. And we know AI learned to read and write based on math. So why on earth would anyone believe math couldn’t also create their ontology?
The new ETL pipeline has AI embedded within it (I affectionately call it “ET-ai-L”).
But most people start out with a very primitive approach. They split PDFs, for example, into smaller, fixed-length, sequential segments to prevent layout structures from being destroyed. This is often referred to as “overlapping chunking.”
Needless to say, this approach generates results that vary widely (and if you really want to make your pipeline engineers spill their tea, ask them how they deal with tables embedded inside PDFs!). Say you feed the Harry Potter books alongside histories of the Salem witch trials into AI using an overlapping chunking methodology. When someone asks a question, the AI agent could report (with complete confidence) that the U.K. has a witch problem in the 20th century!
Funny in an article. Much less so in M&A analyses or supplier negotiations.
A pipeline that uses contextual chunking, on the other hand, preserves the hierarchy while it builds the chunks, which enables AI to reason over the knowledge graph. Ask a question, and the agent understands the context of the information.
In my Harry Potter example, that means an AI agent will know it pulled a passage from chapter three of a children’s fantasy series because the knowledge graph retained the book’s context: the title, chapters, and section headers.
Moving ahead without a knowledge graph is far more dangerous than any reservations you might have. These two risks worry me most:
Back at Oracle, nobody debated whether 12,000 tables needed a map of how they connected. We built it on purpose because the pipeline couldn’t run without it.
Most AI agents now stand where that ETL pipeline once stood, in front of thousands of tables and millions of documents, with nothing to explain how the data connects together. It’s a big, thorny issue you can only overcome with a mathematical ontology-driven knowledge graph.
So put one in place now, before your first thousand agents start delivering confident but wrong answers to important questions.
Find out how 4Minds has reimagined AI to be a living, breathing system of adaptive, contextual intelligence that you control. One that sees clearly across fragmented institutional knowledge. Reasons easily across workflows. Learns continuously. Adapts automatically. And deploys how and where you want it. Visit us at www.4minds.ai.