board: atlas category: projects/atlas kind: main series: ATLAS episode: 6 seriesTotal: 12 visibility: published lang: en publishedAt: 2026-05-26 thumbnail: /api/images/file/848a337941716277.png thumbnailCardRegion: card titleKo: AI가 읽기 좋은 지식 구조를 설계하기 titleEn: Designing a Knowledge Structure an AI Can Read excerptKo: ATLAS의 데이터 모델은 처음부터 설계된 게 아니다. 틀리면서 자라났다. 똑같이 생긴 노드 더미가 어떻게 AI가 실제로 탐색할 수 있는 Node·Tag·Relation이 됐는지에 대한 이야기. excerptEn: ATLAS's data model was never designed up front — it grew by breaking. This is how a flat pile of identical nodes became the Nodes, Tags, and Relations an AI can actually navigate.
It started as just nodes
The first version of ATLAS had no types at all.
A note. An idea. A retrospective. Every one of them was the same node — nothing more than a title, some tags, content, and links.
Search was pure substring matching. To find something, you had to remember the exact words you had written.
Once the notes passed a hundred or so, that structure buckled.
The graph looked good, but it was hard to search
Once I linked the notes together, a graph appeared. It looked great.
There's a graph now, so finding things will be easy. That was the assumption.
But the more notes there were, the more the graph turned into a maze. It was something to look at, not something to search.
So I added tags
First, classification. Project, Study, Health.
I started pinning labels onto nodes, and it helped — for a while.
Then the tags themselves multiplied, until there were too many of them to manage.
So tag creation had to be reined in
At first, anyone — me or the AI — could invent a brand-new tag on the spot, mid-writing. That was exactly how the sprawl happened: health, health-log, health-plan, three tags for one thing.
So I changed the rule. Tags became a managed set. Now, when a note gets tagged, it picks from the tags that already exist — you check what's there first. Creating a genuinely new tag is a separate, deliberate step, not something that slips in while you write.
The pile stopped growing on its own.
I needed a tree, too
People like folders more than they admit.
Drilling down through levels turned out to be far more comfortable than wandering a graph. So I stopped keeping tags as a flat list and let them nest.
personal → health → mental-health → adhd. The tags became a tree, and now there were two ways to move around: the graph and the tree.
Nodes had to be different kinds
Not every node deserved the same weight.
Something I jotted down in a hurry today, a reference I had cleaned up, a conclusion I had distilled from many notes — treating them all as the same kind flattened real differences.
I experimented with a lot of distinctions. It eventually settled into two levels: a broad kind, and a finer sub-kind beneath it. Rather than endlessly adding new types, I split the classification into two axes.
(Which kinds exactly, and why they divide the way they do, is its own post — coming later.)
The AI needed its own notes
Here's the part I care about most.
I never thought of ATLAS as a search box. I thought of it as an assistant.
An assistant doesn't only memorize your information. It does its own work, too. So the AI started writing its own nodes — patterns it noticed, lessons it drew from being corrected.
Why that turns "memory" into something closer to "learning" is a big enough idea to need its own post. I'll come back to it.
"Related" wasn't enough
As the nodes multiplied, a plain "these are related" link stopped being enough.
Not just related, but: this decision supports that plan. This note updates an older one. This idea was derived from another. This fact contradicts an assumption.
So relations got a direction and a meaning. There are around ten relation types now, and a new one gets added whenever a situation calls for it.
And it's still changing
ATLAS's data model isn't a finished design. I'm still experimenting with structures an AI can understand better.
But building a good structure and having the AI actually read it, every single time, turned out to be two different problems. You can't shove a graph of 470-some nodes and over 1,200 relations into every conversation.
Next post: why load_memory is hard.
