3 Layers That Turn Data Into Knowledge

The last essay was about ontology. About the idea that data only becomes useful when you build the relationships between the data points. What that looks like in practice is what I want to describe here.

In the projects I have seen over thirty years, there was almost always a dashboard. Often several. The dashboards looked good and updated themselves. Curves, numbers, all there. But when I asked where a specific number came from and how reliable it was, the search began. The data came from different sources, formatted differently, partly outdated, partly contradictory.

The presentation had been built before the foundation was in place. I call that the tool-first problem.

What you need instead are three layers.

First layer: facts

The bottom layer holds structured facts. Every statement has an origin and a quality rating. And it connects to other statements. This is where you record what you know and how certain you are about it.

Medicine solved this thirty years ago. The GRADE system (Guyatt et al., 2008, BMJ) rates every clinical recommendation on a scale from “very low” to “high.” You can trace why a recommendation was rated “moderate” and which studies were used. Without this rating there is no Cochrane Review. The quality assessment is the first layer.

This is a lot of work. But without this layer, everything you build on top rests on assumptions.

Second layer: interpretation

The second layer is human. This is where decisions live and context. Why did we choose market A over market B? What does the new regulation mean for our business? Where are the gaps in our data?

This cannot be automated. It requires experience and judgment. AI can help with building the first layer. Not the second, at least not on its own.

Third layer: presentation

The third layer is dashboards, reports, visualizations. Nothing new technically. But they only work if the first two layers are in place. Without clean facts and documented decisions, the best dashboard shows nothing but nicely formatted uncertainty.

Why the order matters

Palantir has been building systems this way for over twenty years. In Foundry the ontology is the foundation. The value is in the structure, not the frontend.

The large consulting firms have their own systems by now. But I have seen clients who still work with the old model: order a presentation, receive a recommendation, and the next day the slide is outdated. When the market changes, you have to book the consultants again. That is a service, not a knowledge system.

The order makes the difference. If you start with the presentation, you build on something you cannot verify. If you start with the facts, you can generate any view you need.

In a project of my own I extracted 258 findings from 97 studies. Each with a source reference and a quality rating based on GRADE. That is a first layer under construction. The connections between findings are still missing. They are index cards, not a graph. But the foundation is there, and every view I build from it later will rest on verified facts.

In my experience no stakeholder cares about a knowledge graph. What counts is the dashboard. But the dashboard is only as good as the data underneath.