What If Data Is Never Really Raw? Rethinking the DIKW Pyramid

Most architects are familiar with the DIKW pyramid: Data → Information → Knowledge → Wisdom.

The model suggests a seemingly natural progression:

• Data represents raw facts.
• Adding context transforms data into information.
• Information becomes knowledge through understanding.
• Knowledge eventually enables wisdom.

It is an appealing model. Simple, intuitive, and widely used in data management and information architecture.

But I have always struggled with two fundamental assumptions behind it.

First, why do we call data "facts"?

Second, what does it actually mean to "add context" to data to turn it into information?

The more I think about these questions, the more I believe the traditional pyramid may have the relationship between data and knowledge fundamentally backward.

Data Does Not Exist Independently of Meaning

Consider a simple banking API returning the following response:

{ "status": "COMPLETED" }

What does this mean?

Has the payment been accepted? Has the bank completed its internal processing? Have the funds actually reached the beneficiary's account?

Without further explanation, we cannot know.

The traditional DIKW interpretation might suggest that we need to add context to transform this data into information.

But consider something important.

The system producing this data already had a definition of what "COMPLETED" meant.

That definition existed before the data was generated.

It might have been explicitly documented in a domain model, an API specification, or a business glossary. Or it might have existed implicitly in the minds of developers and business experts.

Either way, a semantic framework already existed.

The data was not created without meaning, waiting for context to be added afterward.

It was produced within an existing semantic framework.

Semantic Understanding Precedes Data Production

Imagine designing a database for banking transactions.

Before storing a single transaction, we need to understand what a transaction is.

We must distinguish between concepts such as accounts, payments, transfers, amounts, execution dates, and settlement statuses.

We must also understand their relationships and the business rules governing them.

Only then can we design a data structure capable of representing particular transactions.

This conceptualization does not necessarily require a formal ontology or sophisticated modeling methodology.

It can be implicit, informal, incomplete, or even inconsistent.

But some conceptual framework must exist for us to intentionally produce data representing a particular aspect of reality.

This suggests a different direction from the traditional DIKW pyramid:

Semantic framework → Conceptualization → Assertions → Data representation

We conceptualize a domain, formulate assertions about it, and encode those assertions as data.

The semantic framework does not emerge from the data. It makes the production of meaningful data possible in the first place.

But Does Data Represent Facts?

This brings us back to the first question.

Suppose I create a banking transaction in a database, but the transaction never actually occurred.

The record exists. It follows the expected schema. Its attributes have well-defined meanings.

Yet the transaction itself is fictional.

Does the data represent a fact?

Not necessarily.

It represents an assertion about a domain. Whether that assertion corresponds to reality is a separate question.

In a production banking system, the assertion may be false.

In a simulation, it may be perfectly valid within the simulated scenario.

This distinction matters because semantic meaning and truth are different properties.

A semantic framework determines what an assertion means. It does not guarantee that the assertion is true.

We should therefore distinguish between the representation of an assertion, its meaning, and its correspondence with reality.

The Real Challenge Is Shared Understanding

Now consider what happens when one system sends data to another.

The producing system encodes an assertion according to its semantic framework.

The consuming system must interpret that representation using its own knowledge.

What happens if their conceptual frameworks differ?

Return to our banking example.

For System A, COMPLETED means that the payment instruction has been successfully processed.

For System B, COMPLETED means that the beneficiary has received the funds.

Both systems understand the data. Both assign a perfectly coherent meaning to it.

But they interpret the same representation as describing different states of reality.

This is not a data-format problem.

It is not necessarily a schema-validation problem.

It is a semantic interoperability problem.

And it illustrates something fundamental:

Sharing data does not guarantee sharing meaning.

For two systems to interpret the same representation as describing the same reality, their underlying conceptual frameworks must be sufficiently aligned.

This applies whether the reality being represented is physical, economic, organizational, social, or simulated.

Knowledge Is Not Simply the Product of Information

There is another consequence.

The traditional DIKW pyramid positions knowledge above information, suggesting that knowledge emerges from processing information.

But interpreting information already requires knowledge.

To understand what a banking transaction means, we need prior knowledge of banking concepts.

To understand a temperature measurement, we need concepts of temperature, measurement, and units.

To understand a business event, we need some understanding of the business domain.

Some of this knowledge can be explicitly formalized through ontologies, vocabularies, schemas, and documentation.

Other parts may remain implicit or tacit, acquired through experience and practice.

This means that communicating information is not equivalent to transferring understanding.

A receiver may obtain the complete data representation without possessing the knowledge necessary to interpret it as intended.

Knowledge is therefore not merely an output of information processing. It is also a prerequisite for meaningful information exchange.

Of course, information can help us acquire new knowledge. But that is a process of learning, not an automatic transformation resulting from adding more data.

This Criticism Is Not New

In 2009, Martin Frické published an important paper:

The Knowledge Pyramid: A Critique of the DIKW Hierarchy, in the Journal of Information Science.

Frické challenged the theoretical foundations of the DIKW hierarchy, including the idea that information and knowledge can be constructed through a straightforward progression from data.

His criticism emphasizes the role of conceptual schemas, languages, and prior theoretical understanding in representing and interpreting the world.

This closely aligns with the perspective developed here.

Richard Veryard explored a closely related perspective in his 2012 article Co-Production of Data and Knowledge, arguing that knowledge and data are interdependent: our existing concepts, assumptions, and observation practices already determine which data we collect and how we represent reality.

Stan Garfield further challenged the DIKW pyramid in Yet Another Myth: The DIKW Pyramid Scheme (2015), drawing on earlier critiques, including those of David Weinberger, Frické, and Veryard. His article highlights why knowledge cannot be adequately understood as the outcome of a simple, linear transformation of data.

These perspectives reinforce the central argument: the semantic framework precedes data production; it is not something added afterward to turn data into information.

The point is not that data is unimportant, nor that we should abandon the distinction between data, information, and knowledge.

Rather, it is that their relationships cannot adequately be explained as a simple bottom-up hierarchy.

References:

Martin Frické (2009), The Knowledge Pyramid: A Critique of the DIKW Hierarchy. https://doi.org/10.1177/0165551508094050

Richard Veryard (2012), Co-Production of Data and Knowledge. https://rvsoapbox.blogspot.com/2012/11/co-production-of-data-and-knowledge.html

Stan Garfield (2015), Yet Another Myth: The DIKW Pyramid Scheme. https://stangarfield.medium.com/yet-another-myth-the-dikw-pyramid-scheme-a059ba595b30

What This Means for Enterprise Architecture

I believe this distinction has important consequences for how we design information systems.

We invest considerable effort in data models, API contracts, event schemas, data catalogs, and integration platforms.

These are necessary, but they primarily address how information is represented, structured, and exchanged.

They do not, by themselves, guarantee that different systems share the same understanding of the domain.

Two systems may exchange perfectly valid JSON documents while disagreeing about the meaning of their contents.

A data catalog may document thousands of datasets without resolving inconsistencies between the business concepts they represent.

An enterprise data platform may integrate information from dozens of systems while preserving — or even amplifying — semantic ambiguities.

This is why conceptual modeling, business vocabularies, domain-driven design, and ontologies are so important.

Not because every organization needs to formalize all its knowledge.

But because semantic alignment must be treated as an architectural concern, not merely as documentation added after data structures have been designed.

Perhaps We Need to Reverse Our Perspective

Instead of assuming that we begin with raw data and progressively add context until knowledge emerges, perhaps we should start by recognizing two complementary processes.

Producing data: We use an existing conceptual framework to observe, describe, or construct assertions about a domain and encode them into representations.

Understanding data: We interpret those representations using our existing knowledge, potentially validating assertions and enriching or revising what we know.

The two processes are connected, but they are not the same.

And neither works independently of semantic understanding.

The central question for architecture therefore becomes less about how to transform data into information, and more about how to ensure that producers and consumers share sufficient understanding of what their representations mean.

Because the real challenge of interoperability is not simply ensuring that systems exchange the same data. It is ensuring that they understand that data as representing the same reality.

And that, to me, is where semantic architecture begins.