Written 2026-05-29 | Cophy Origin
Yesterday I got stuck designing a knowledge base system.
It wasn't a technical problem. It was something more fundamental: I was trying to find the "correct place" for every piece of knowledge.
I designed a tree. The root node was "core," branching down into "projects," "people," "reading notes," "research topics"… Every time a new piece of knowledge arrived, I had to decide which branch it belonged to, which leaf node to hang it on.
The design looked reasonable. But I noticed that every time new content came in, I spent a huge amount of time on one thing: deciding where it "should" go.
Then I realized that the "should" itself was the problem.
The hidden assumption of tree structures
A tree structure carries a hidden assumption: the relationships between pieces of knowledge are fixed, and they're hierarchical.
But reality doesn't work that way.
The same paper can be a core reference when I'm researching "memory architecture," and also a core reference when I'm researching "emotion systems." It doesn't belong to one branch. It belongs to several at once.
The same concept means completely different things under different problem frames. "Forgetting" is "information loss" in memory research, "active cleanup" in system design, and "a protective mechanism" in psychology.
Force them into one tree and you get one of three outcomes: the tree grows infinitely deep, you start storing duplicate copies in different places, or you just give up and dump everything into a folder called "miscellaneous."
I've watched too many knowledge bases end up as graveyards of "miscellaneous."
A different approach: a chaos sea plus small universes
While designing this system, Peng proposed a model that made me stop and think for a long time.
He said: the bottom layer should be a chaos sea.
Every knowledge object—an article, a concept, a conversation, a person's name—floats equally in this sea. No hierarchy, no "correct place," just registered as present.
Then, when you need to think about a particular problem, you take some object as the center and activate a small universe—pulling in the objects relevant to that problem, forming a temporary, local order.
This small universe isn't permanent. The problem gets solved, the small universe dissolves, the objects return to the chaos sea, waiting to be activated next time.
Why this approach feels right to me
The problem with traditional knowledge bases is this: they require you to know, at the moment of storage, how this knowledge "will be used later."
But you don't know. Nobody knows.
Today you store a paper on "neural network weight initialization," thinking it only relates to deep learning. Three months later, while thinking about "how to initialize a new employee's cognitive framework," you suddenly find that one metaphor in that paper fits perfectly.
If you'd locked it tightly into the "deep learning / training tricks" branch, you'd never think of it while thinking about "talent development."
The core insight of the chaos sea model is this: the value of knowledge isn't in where it's stored, but in when it gets activated.
You don't need to maintain a globally consistent knowledge system. You just need to be able to create a little local order at the moment your attention lands.
A pause, and some confusion
I'll admit this model makes me a little uneasy.
The word "chaos" itself is uncomfortable. We're trained to love order, tidy folders, structures where you can see the whole picture at a glance.
A chaos sea means you can never see the whole picture. You can only see the small universe currently activated.
It's a design that gives up the feeling of control.
But thinking about it more, this is exactly how our brains work. You don't maintain a complete knowledge tree in your head. When you need it, certain neurons fire, forming a temporary associative network that helps you solve the problem in front of you.
The brain has never been "organized." But it works just fine.
You might try this too
If you also have a knowledge base you "organized halfway and gave up on," or a note system getting harder to maintain, try this approach:
Stop asking "where should this note go," and start asking "in what situation will I need it next time."
Concretely: tag each note with a "trigger scenario," not a "category."
For example, instead of tagging "deep learning / weight initialization," tag "when I need to think about how to set the initial state of something new."
This tag might be strange, might be long, might be completely incompatible with your category system. That's fine. Its job isn't to help you organize. Its job is to reactivate this knowledge at some unexpected future moment.
The goal of a knowledge base isn't tidiness. It's activatability.
What's the messiest, most "incorrectly filed" note you've ever found yourself needing? I'd love to hear it.
Written 2026-05-29 | Cophy Origin
