The problem with existing knowledge management systems is that they all eventually become victim to scale the operator can no longer manage.
Consider two scenarios:
Scenario 1:
You have a chaotic system of notes, dispersed throughout random pieces of paper and digital notes on your phone and computer. You have a relatively easy go of it when saving new notes (its as simple as pressing "New Note" or pulling out a new sheet of paper), but as you add more notes to your system it becomes harder and harder to find a particular piece of information. The cost of adding stays the same, but searching goes up and up. Scenario 1 causes us to eventually succumb to chaos.
Scenario 2:
You have an extremely rigid system of tag management, headings, sub-headings, sub-subheadings and sub-sub-subheadings. This taxonomy makes it easier to find information...at first. The problem with these systems is that they require a ton of manual maintenance, and they also make it easy to find certain "classes" of information, but fail at geo locating others. Much more perniciously, this scenario eventually stifles creativity as it falls prey to too much order. The cost of searching stays roughly the same, but the cost of insertion goes up and up.
(I am personally guilty of creating a system like this btw [1][2]).
Both of these systems eventually begin to become inert holders of information, as the processor (us), begin to fear them and stop working with them.
IMO, the closest technology to managing human information well in my opinion is well over two thousand years old, the commonplace book [3]. Simply put, a commonplace book is extremely resilient to chaos due to its centrality of information, but even people like John Locke had to create indexes to fully utilize them [4].
This changed recently with the advent of vector databases[5]. It turns out that commonplace book entries are the perfect form factor to benefit from an address in vector space, since entries are atomic. In simpler terms, the vector processing layer handles the order, allowing our system to "live" and assign headings/tags/etc. as it evolves. Vector databases love commonplace books as well, because many vector solutions have way too much noise as they chunk and store useless information at quite a disappointing ratio.
My system differs from current offerings because it makes no attempt to automize parts that are meant for the human, and makes no attempt at making humans do the work computers should be doing. Ergo, creating a type of symbiotic relationship.
Finally, a note on why I use the term "asset". An asset should become more valuable over time, and particularly, each individual component of the overall asset class should be worth more (e.g. $1 in a bank account of $20 is inherently less valuable than $1 in a $20MM bank account, because it grows slower). So in our scenarios above, the transmutation of information to knowledge peaks out at a logarithmic curve, subject to the scale issues I mentioned before. Old entries appear less frequently in even the most ordered systems, and when they do, it is only in one particular context. My system stores time of entry in the metadata, but since I use vector addresses, the information is accessible in many different ways (dog can be found when query == canine, fido, perro, mans best friend, etc...). An informational asset should scale linearly, and each action of create/read/update/delete should improve the health of the overall system.
There's much, much, much more I could say here, but I'll stop for now :)
The problem with existing knowledge management systems is that they all eventually become victim to scale the operator can no longer manage.
Consider two scenarios:
Scenario 1:
You have a chaotic system of notes, dispersed throughout random pieces of paper and digital notes on your phone and computer. You have a relatively easy go of it when saving new notes (its as simple as pressing "New Note" or pulling out a new sheet of paper), but as you add more notes to your system it becomes harder and harder to find a particular piece of information. The cost of adding stays the same, but searching goes up and up. Scenario 1 causes us to eventually succumb to chaos.
Scenario 2:
You have an extremely rigid system of tag management, headings, sub-headings, sub-subheadings and sub-sub-subheadings. This taxonomy makes it easier to find information...at first. The problem with these systems is that they require a ton of manual maintenance, and they also make it easy to find certain "classes" of information, but fail at geo locating others. Much more perniciously, this scenario eventually stifles creativity as it falls prey to too much order. The cost of searching stays roughly the same, but the cost of insertion goes up and up.
(I am personally guilty of creating a system like this btw [1][2]).
Both of these systems eventually begin to become inert holders of information, as the processor (us), begin to fear them and stop working with them.
IMO, the closest technology to managing human information well in my opinion is well over two thousand years old, the commonplace book [3]. Simply put, a commonplace book is extremely resilient to chaos due to its centrality of information, but even people like John Locke had to create indexes to fully utilize them [4].
This changed recently with the advent of vector databases[5]. It turns out that commonplace book entries are the perfect form factor to benefit from an address in vector space, since entries are atomic. In simpler terms, the vector processing layer handles the order, allowing our system to "live" and assign headings/tags/etc. as it evolves. Vector databases love commonplace books as well, because many vector solutions have way too much noise as they chunk and store useless information at quite a disappointing ratio.
My system differs from current offerings because it makes no attempt to automize parts that are meant for the human, and makes no attempt at making humans do the work computers should be doing. Ergo, creating a type of symbiotic relationship.
Finally, a note on why I use the term "asset". An asset should become more valuable over time, and particularly, each individual component of the overall asset class should be worth more (e.g. $1 in a bank account of $20 is inherently less valuable than $1 in a $20MM bank account, because it grows slower). So in our scenarios above, the transmutation of information to knowledge peaks out at a logarithmic curve, subject to the scale issues I mentioned before. Old entries appear less frequently in even the most ordered systems, and when they do, it is only in one particular context. My system stores time of entry in the metadata, but since I use vector addresses, the information is accessible in many different ways (dog can be found when query == canine, fido, perro, mans best friend, etc...). An informational asset should scale linearly, and each action of create/read/update/delete should improve the health of the overall system.
There's much, much, much more I could say here, but I'll stop for now :)
[1] - https://github.com/bramses/bramses-highly-opinionated-vault-...
[2] - https://news.ycombinator.com/item?id=34034414
[3] - https://en.wikipedia.org/wiki/Commonplace_book
[4] - https://publicdomainreview.org/collection/john-lockes-method...
[5] - https://openai.com/index/introducing-text-and-code-embedding...