5 July 2026·Engineering·3 min read · 570 words

The knowledge system, part 1: capture versus structure

Two knowledge bases and one stalled migration later, the tool was never the problem. Structure and capture were.

I ran my personal knowledge base in MyBase for years. Wiki-like, tree structured, every note living inside a folder inside a folder. It looked organised on day one.

It stayed organised for about as long as I could remember which branch a note lived under.

Where I started

The tree assumed I knew, upfront, how a piece of information related to everything else already in there. Half the time I didn't. I'd create a category, file a handful of notes under it, then months later forget the category existed and create a near duplicate somewhere else. Finding something meant remembering not what it said, but where I'd filed it.

That's the actual failure. Not "it got messy" in the abstract. I knew the information existed somewhere in the vault, and I still couldn't get it out within a reasonable time.

The migration that stalled

At some point I tried moving to Obsidian. Backlinks instead of folders, notes linking to each other instead of sitting in a hierarchy. It looked like the fix for what MyBase got wrong.

It wasn't. The migration itself is where things fell apart. Converting a tree of documents into a graph of links isn't mechanical. It's a judgement call, repeated for every note: what does this actually connect to. I made that call for a while, then stopped. Some notes made it across. Most didn't. I ended up running two systems, neither complete, with no clear sense of which one was authoritative for anything.

The trade-off

Looking back, MyBase and Obsidian weren't different answers. They were the same trade-off wearing different clothes.

More structure, more friction. A tree demands you decide where something belongs before you've finished thinking about what it is.

Less structure, less friction, less organisation. A graph of backlinks captures fast, but links are only as good as the discipline behind them, and discipline decays under volume.

Every attempt to add structure increases friction. Every attempt to reduce friction decreases structure. Databases, wikis, personal knowledge systems, they all sit somewhere on that line. Pick a position, absorb the cost that comes with it.

A third option

What actually changed wasn't the note taking tool. It was realising I'd been asking one system, and by extension myself, to do two jobs that don't suit the same worker.

Capturing information well means low friction: fast entry, no upfront decisions about where something belongs or what it means. Organising information well means the opposite: consistent categorisation, resolved relationships, maintenance as new information arrives and old assumptions stop holding.

A human does the first job well. Noticing that something matters, and roughly why, happens in the moment, cheaply, almost as a side effect of paying attention.

A human does the second job badly, not from lack of discipline but because it's repetitive, ongoing, and invisible when done well. Nobody notices well organised information. Everybody notices when it's missing.

This is where large language models change the shape of the problem. Not because they're clever. Because they're patient in a way humans aren't, at a job humans were never suited to in the first place: extracting, linking, normalising, maintaining, doing it again tomorrow when a new note lands.

The unit of value was never the tool that stores the notes. It's deciding, deliberately, that capture and curation are different jobs, and giving each to whoever can actually do it well.

That split is worth unpacking properly. That's what part 2 is for.