Meaning Is Not Metadata
An Afterthought to Against the Stream
TL;DR — Metadata is descriptive and secondary — it points at data that already exists. Meaning is constitutive and primary — it precedes data and is what data should have been derived from. The semantic layer treats meaning as an annotation, when it is actually a foundation. You cannot retrofit a foundation. If you want AI to reason about your domain rather than hallucinate about it, you need a domain model constituted from meaning, not annotated toward it.
Some arguments need time to settle before their full weight becomes clear. Against the Stream made the case that most business-language modeling artifacts flow in the wrong direction — they enter the river midstream, assume vocabulary is already established, and call the resulting drift alignment. The argument was about directionality. But a question has been nagging since: why does the direction matter so fundamentally? What is it, precisely, that gets lost when you start from the wrong end?
The answer is deceptively simple, and it changes everything.
What We Lost When We Fed the Machine
We ask AI to find meaning in our data — but the authentic story was gone before it ever looked
In What We Lost When Datum Became Data, I traced how a word that once meant "something given" shed its own etymology and became a synonym for "values in a system." Along the way, the who, the why, and the context quietly disappeared. I used the Groningen definition, the Employee-Person example, and the metadata stack to show where those losses happen.
That argument had its own reasons. It has sharper ones now.
What we lost when Datum became Data
A Word That Carried Its Own Philosophy
In Dutch, the everyday word for data is gegevens. It is not a technical term. Any citizen uses it naturally, without a second thought. And yet it encodes something profound: gegevens are things given — handed over, recorded, established by someone, for someone, with intent.
The English word 'data' has the same Latin root. Datum means 'something given'. But that etymology is effectively dead in English practice. Nobody says "one datum" anymore. Nobody asks "given by whom, for what?" The word has shed its own origin.
What remained is a term that implies objectivity, neutrality, and independence from any observer. Data just exists. It is out there. You collect it, store it, analyse it. The act of creation — the who, the why, the context — has quietly disappeared.
That disappearance has consequences.
The Void That Thinks
What Ancient Wisdom Teaches Us About Working With AI
The Oldest Observation
Ancient Hebrew texts describe the moment before creation as tohu va-vohu — formless and void. Not empty in a trivial sense, but charged with potential. What is striking is not the nothingness itself, but that it was considered real enough to name, to describe, and to stand in relation to.
The Kabbalistic tradition deepens this with Ayin — the nothingness that precedes all being. The void is not the absence of reality. It is a different kind of reality.
Now consider your own experience of not knowing something. It is not a blank. It has texture. It draws you toward it. You can dwell inside it, sit with it, let it work on you. Unknowing is not the opposite of knowing — it is a generative state, a threshold, a beginning.
This is a profoundly human capacity. And it is precisely what AI cannot do.
Understanding the difference — and learning to use it deliberately — will make you a better user of AI, and a better information modeler.
..you can inhabit it. And when you do, you change what AI can do for you..
Against the stream
Why Most "Business Language" Artifacts Flow the Wrong Way
TL;DR — Most artifacts that claim to speak "business language" — DDD context maps, OWL ontologies, Gherkin scenarios, DSLs — are built from the technical side and traveled toward business readability. They flow against the current. Genuine business language originates from the natural sentences domain experts actually use, and is formalized from there toward technical implementation. The direction of derivation is not a detail. It determines whether a model is owned by the business or merely legible to it.
FCO-IM Is Not Telling You What to Build
Solution Architects are trained to design. They come to a project with experience, patterns, and hard-won instincts about how systems should be structured. When a formal model lands in their hands, their first instinct is a reasonable one: does this tell me how to build it? And when it seems to, the friction begins.
This is the misreading that costs organizations dearly. FCO-IM artifacts — the outputs of CaseTalk's fact-oriented conceptual modeling process — are not architectural mandates. They are not database schemas dressed up in business language. They are something more fundamental, and more valuable: a precise, validated record of how the business talks about its data.
"FCO-IM doesn't design your solution — it defines the business reality your solution must respect."
That distinction matters enormously. A Solution Architect is free to implement a star schema, a graph database, a microservice mesh, or an event-driven platform. The FCO-IM model does not care. What it does care about — what it was built to preserve — is whether the distinctions that matter to the business survive the translation into technology.
The Data That Doesn't Know What It Means
How entity modeling quietly discarded the meaning AI is now desperately trying to recover
The Billion-Dollar Semantic Recovery Project
There is a quiet crisis at the heart of enterprise AI adoption, and almost nobody is naming it correctly.
Organizations are investing heavily in semantic layers, knowledge graphs, ontologies, and AI-powered data catalogues. The pitch is always some variation of the same idea: we will make our data understandable — to machines, to analysts, to the business. We will surface meaning from our data assets.
What is rarely said out loud is the uncomfortable premise underneath all of that investment: the data doesn't already know what it means.
That is not a technology problem. It is not something a better LLM will fix, or a richer graph schema, or a more expressive ontology language. It is a modeling problem — specifically, a problem that was baked in decades ago when organizations chose how to represent information, and what to keep and what to throw away.
This article is about what was thrown away, why it is so hard to get back, and why there is a family of modeling approaches that never threw it away in the first place.
Download 
Try Online
Use Online