Storage keeps data. Semantics records what that data means and how concepts relate. This article explains why a data project should start with meaning, not with tables, and how one semantic layer prevents dashboards and AI agents from filling in the same term differently.
Kees Pronk
CEO
A table full of customer numbers, PLUs and supplier data tells you nothing as long as nobody records what those numbers mean. That is the difference between semantics versus storage: storage keeps the data, semantics records what that data means and how concepts relate to each other. With a data project approach that only looks at storage, you sooner or later get stuck on differences in interpretation between departments.
A storage-oriented approach is about structure: tables, columns, keys. Semantic modelling (recording meaning and relationships between concepts) is about interpretation: what is an "active customer", what counts as "revenue"?
A database can work flawlessly and still be used incorrectly, simply because two departments have a different picture of the same field. Fix that with one owner per concept, recorded outside the head of a single employee.
The same number means something else depending on the situation in which it is used. That variety of meaning arises because the same term takes on a different charge in different departments.
"Revenue" can be gross or net, with or without returns, per order or per invoice. Contextual specification (recording the precise meaning of a concept per situation) prevents a dashboard and an AI agent from filling in the same term differently. Record per concept in which context it applies, and who decides on that.
Systems that share the same meaning layer can talk to each other without manual translation work. Without that layer you rebuild the translation between system A and system B with every connection.
Semantic interoperability only works if the meaning layer stands apart from the underlying system. Set up the semantic layer therefore as a separate part of your platform, not as a property of one specific tool or database.
A data project approach that starts with semantics prevents you from having to go back on agreements halfway through a project. In practice we see at clients that most delay comes from discussion about meaning, not from technical obstacles.
Therefore do not start with the storage structure, but with the question which concepts exist and who owns each definition. Work that out before you set up a Bronze, Silver or Gold layer (the successive processing steps from raw to usable data). That way you prevent an AI layer from later calculating on assumptions that nobody has recorded.
A recurring anti-pattern: the same term with different definitions in different systems, without anyone noticing until a report and a dashboard contradict each other. With an AI layer this weighs more heavily than with a dashboard. In a chart you see a kink, in a generated sentence you do not.
A working pattern: one semantic layer above the storage, with a fixed owner per concept and a clear link to the underlying Silver layer. Set that layer up before you add automation or AI, not afterwards.
Semantics versus storage is not a technical choice but a question of sequence: first record meaning, only then automate or visualise. Messy definitions are work, not a luxury to skip. Unsure where to start with your data project approach? Book a Discovery Call and we will tell you honestly.
Author
CEO
Boards often ask for a better dashboard, while the real split is signalling versus reporting. One shows what happened; the other acts when it counts.
Kees Pronk
CEO
A portal that works at three clients often stalls at thirty. How row-level security and a multi-tenant setup replace manual rights work.
Kees Pronk
CEO
One shared report, each user only sees the rows they are entitled to. How boards share data with staff, partners and customers without losing control.
Kees Pronk
CEO
