Strong piece. The data plane / knowledge plane framing is the cleanest articulation I've read of something I've been hitting for years on the implementation side.
The trap most teams fall into, even when they take "knowledge layer" seriously: they reach for a vector store and call it done. But a similarity index isn't a knowledge plane, it's a retrieval shortcut. Ask it to enumerate, count, or aggregate across the knowledge it supposedly holds, and it collapses. An index can't count. A database can.
What we've ended up building with Sandra (open source, github.com/everdreamsoft/sandra) is essentially the knowledge plane you describe, made concrete: concepts as first-class entities with stable IDs, typed factories backed by SQL, triplets with temporal validity, and embeddings layered on top of structured storage, not in place of it. The structured side handles enumeration, aggregation, reconciliation. The semantic side handles fuzzy recall. Most "memory for agents" products on the market today still skip the first half.
One thing your framing nails that I want to underline: this layer outlives the data stack underneath it. We've been running the same conceptual graph across five production environments at EverdreamSoft for years (Spells of Genesis-game- Tokenized asset index...), while the apps and DBs around it have turned over. The knowledge plane really does decouple, when it's treated as its own substrate.
Looking forward to the rest of the series. "Conceptual modeling is the context engineering nobody is doing" should be on a t-shirt.
This is exactly what we’re working on over at oiya.ai - the semantic layer that you mentioned does seem to cover it, though? You need something like a labelled property graph, maybe even an ontology to make cross-silo understanding work.
So, how to perform this conceptual modelling in practice? Is it something different than building an ontology of concept definitions by re-using resources from e.g. SKOS? I'm a bit confused if this is "walk around the porridge" (as we say in Norway), or if it's just describing ontology practises with different terminology. I'm curios!
It's a different approach aiming at capturing pretty much the same information. There are two as-of-yet completely separate schools of thought, one coming from the knowledge management world (like you, I presume) and one coming from the data world (like me). Both have their practices, methods, and standards. The goals are the same, more or less - and that's what I'm trying to emphasize with many of my writings :) It's just that our schools are so completely separate that people often completely fail to understand the other side's thinking and terminology!
If you're interested in learning the "how" of conceptual modeling from the data side, I'm writing a book on that with Shane Gibson ;)
Very true ! This is still very underrated and yet a game changer.
100% yes!!
Strong piece. The data plane / knowledge plane framing is the cleanest articulation I've read of something I've been hitting for years on the implementation side.
The trap most teams fall into, even when they take "knowledge layer" seriously: they reach for a vector store and call it done. But a similarity index isn't a knowledge plane, it's a retrieval shortcut. Ask it to enumerate, count, or aggregate across the knowledge it supposedly holds, and it collapses. An index can't count. A database can.
What we've ended up building with Sandra (open source, github.com/everdreamsoft/sandra) is essentially the knowledge plane you describe, made concrete: concepts as first-class entities with stable IDs, typed factories backed by SQL, triplets with temporal validity, and embeddings layered on top of structured storage, not in place of it. The structured side handles enumeration, aggregation, reconciliation. The semantic side handles fuzzy recall. Most "memory for agents" products on the market today still skip the first half.
One thing your framing nails that I want to underline: this layer outlives the data stack underneath it. We've been running the same conceptual graph across five production environments at EverdreamSoft for years (Spells of Genesis-game- Tokenized asset index...), while the apps and DBs around it have turned over. The knowledge plane really does decouple, when it's treated as its own substrate.
Looking forward to the rest of the series. "Conceptual modeling is the context engineering nobody is doing" should be on a t-shirt.
This is exactly what we’re working on over at oiya.ai - the semantic layer that you mentioned does seem to cover it, though? You need something like a labelled property graph, maybe even an ontology to make cross-silo understanding work.
So, how to perform this conceptual modelling in practice? Is it something different than building an ontology of concept definitions by re-using resources from e.g. SKOS? I'm a bit confused if this is "walk around the porridge" (as we say in Norway), or if it's just describing ontology practises with different terminology. I'm curios!
(And maybe this is of interest to you; https://substack.com/home/post/p-191015846 :-) )
It's a different approach aiming at capturing pretty much the same information. There are two as-of-yet completely separate schools of thought, one coming from the knowledge management world (like you, I presume) and one coming from the data world (like me). Both have their practices, methods, and standards. The goals are the same, more or less - and that's what I'm trying to emphasize with many of my writings :) It's just that our schools are so completely separate that people often completely fail to understand the other side's thinking and terminology!
If you're interested in learning the "how" of conceptual modeling from the data side, I'm writing a book on that with Shane Gibson ;)