Jack Jansonius published an article, “When Data Doesn’t Know What It Means.”

Many enterprise data systems suffer from a hidden problem: the data no longer “knows” what it means. Over decades, business meaning has been fragmented across processes, rules and technical structures, making systems increasingly opaque and difficult to control.

Meaning-driven architecture offers an alternative. By explicitly modelling goals, decisions and domain concepts, systems become transparent, testable and easier to govern. Instead of hiding logic in process flows or rule sets, decision tables make reasoning explicit—providing a stable semantic foundation for both traditional IT and AI. Link

Traditional IT tends to organize systems around processes, data structures, and rules. Business logic is distributed across workflow diagrams, service orchestration, scripts, and rule fragments. The result is familiar to anyone who has worked in large systems: process spaghetti in BPM environments, and rule spaghetti in large rule engines. The underlying issue is the same in both cases. The real business reasoning of the organization is hidden inside technical control structures.

When decisions are implicit, systems accumulate process spaghetti or rule spaghetti.

This is why systems become opaque over time. You can see the flows, the rules, and the data fields, but it becomes increasingly difficult to answer the simple question: what decision is actually being made here, and why?

A more stable architectural approach starts somewhere else: with meaning.

Meaning-driven architecture is not about vague interpretations or philosophical abstraction. On the contrary, it is about making the structure of meaning in an organization explicit and operational. That means modelling three things clearly:

• the goals the organization pursues
• the decisions that realize those goals
• the domain concepts that give those decisions a consistent semantic basis.