Why Your $12 Notebook Beats Every AI Knowledge App
The bullet journal as a structured authoring system
Most AI note apps bundle storage, structure, and access into one product and get at least one wrong — a $12 bullet journal doesn't. Drawing on structured authoring and Ryder Carroll's method, this piece shows how to separate what stays in the notebook from what graduates into a structured, AI-searchable knowledge base.
The best PKM I’ve used doesn’t sync, doesn’t have an AI layer, and has never been acquired or sunset by a startup out of money.
It’s a $12 notebook ... and it solves the three problems that I wrote about in my last piece on knowledge management (and what most apps get wrong): storage, structure, and access.
I know I promised a deep dive into the anatomy of a skill not too long ago, and honestly, it was scheduled for today.
But work I’ve been doing with my bullet journal turned out to be more relevant to how I’m thinking about personal knowledge management (PKM) right now, so that piece is back in the queue.
In fact, I’d argue that if you actually want to understand how a PKM works, or how a skill should be structured, you have to start at the most basic level there is ... analog.
I don’t write about this much here, but a notebook has been my first-layer PKM tool off and on for years, specifically the bullet journal method.
I slipped away from it for a stretch, chasing what I was sure would be the perfect AI-powered PKM instead.
I wrote a Substack note about that particular rabbit hole, but it turned out to be more relevant to my explorations than I thought.
These days I’m using my bullet journal as my launch pad for experiments with local markdown knowledge bases for AI (which is where all this is going!).
Prepping for a bullet journal community panel a few weeks back is what got me thinking about this connection again.
But wait ... I’m not talking about the versions of bullet journal with stickers and washi tape you see all over Instagram. I mean the original method, the one Ryder Carroll actually designed.
If you’re looking for a PKM that gets all three parts right, start with this kind of bullet journal.
I spent last week’s piece cataloging every AI note app I’ve adopted and abandoned and how the root of the problem was my inability to control and fine tune the three layers of knowledge management:
Storage, or where it lives.
Structure, or how it’s organized.
Access, or how AI actually reads it.
Almost nothing on the market treats them as three individual units.
If you think about it, analog has been getting this right for centuries ... and is probably why it sticks around no matter how far technology advances.
I teach and research professional writing at a university, but the part of my job that’s actually shaped how I keep that notebook has less to do with the classroom.
For the past several years I’ve worked in structured authoring, a field that mostly lives inside technical writing and enterprise content teams who write documentation for medical devices, aircraft manuals, software APIs, etc.
Many of you reading this newsletter already know what structured authoring is. If you don’t, that’s normal. It’s not really a productivity philosophy, but a way to think about how we build and use information.
What is structured authoring
For those of you unfamiliar, here’s what that looks like in practice.
An aircraft maintenance manual has to hold a torque spec for a bolt, a warning about what happens if you skip a step, and the numbered procedure for replacing a part.
Those look like they could all live on the same page in paragraphs, and in a bad manual, they do.
But they’re three different kinds of information, doing three different jobs for the reader.
The torque spec is something a mechanic looks up and moves on. It’s a fact, and it shouldn’t change based on context.
The warning is a rule. Follow it or don’t, but it’s not a step in a sequence.
The replacement procedure is something the mechanic actually performs one action at a time.
Collapse those three into one undifferentiated block of text, and the mechanic reaching for a torque value in the middle of a repair has to read past a warning and a procedure to find it.
Keep them typed separately, and each one is exactly where it needs to be the moment someone needs it.
Most PKM approaches rely on storage schemes.
They tell you which folder or list something belongs in. They don’t ask what the thing actually is.
Knowledge items have a purpose. A fact is something you’ll look up later. A rule you’re supposed to follow. A step is something you’re going to perform.
That’s where structured authoring begins. Knowing what kind of information something is will tell you where it goes. You don’t need fancy acronyms.
Long before I had language for any of this, I was already doing a rough version of it every morning with a pen in my bullet journal.
Bullet journal as a structured authoring tool
Ryder Carroll doesn’t call bullet journalling structured authoring.
But he built the notebook around structural moves that map onto three key elements of structured authoring and information design.
A single source of truth. Carroll’s rule is that everything lives in one place, in order, as it happens ... not scattered across sticky notes, apps, and the backs of receipts.
That’s the same principle behind a single-sourced content repository for an airplane mechanic or software company.
There should be one authoritative location for information, so nobody’s ever working from a stale copy or hunting across three systems for the current version.
For us, the notebook is the repository. Its authority comes from being the only place you go to first.
That’s the storage layer that I wrote about in my last post.
Modularity. Carroll compares the bujo system to a Lego set built from discrete pieces you can rearrange without rebuilding the whole thing.
The clearest version of this is rapid logging, where every entry gets marked with a symbol before you write it, and that symbol is really just an information type:
a dot for something you’ll perform,
a circle for a fact tied to a moment in time,
a dash for an idea you’re not ready to classify yet.
Three different jobs, sorted at the point of capture instead of after the fact ... the same way you would build an airplane mechanic manual.
That’s the structure layer part of the knowledge system.
Nothing in the notebook is readable by anything except me until I decide otherwise.
There’s no export button pointed at a model, no ambient permission sitting open by default.
That’s the access layer. You control who and what sees that notebook.
Iterative assembly. Carroll didn’t design the system top-down. He built it one challenge at a time.
Structured content systems get built the same way, when they work. Nobody architects the whole taxonomy in advance and gets it right the first time.
The bullet journal is essentially a structured authoring system that happens to run on paper, assembled by someone solving his own problem without ever needing the technical vocabulary for what he was doing.
It also happens to get the hardest of the three jobs right, by refusing to solve it prematurely.
What this changes about how I actually use it
Knowing that the notebook is already doing this work changes how I use it. Most of what lands on a daily page never leaves.
A task gets done or migrated.
An event passes.
A note gets read once, maybe referenced for a week, and then its job is finished.
The bullet journal is built for things that are useful now and stop being useful soon after, which is most of what a day is made of.
It takes effort to move something from your bullet journal to a personal knowledge management system, so it better count.
This means it is something worth finding and using again some day. When that is the case, I ask myself three things:
Who’s actually going to read this again?
How will that “who” find it when they come looking?
Is this settled, or still moving (something I need to review)?
A note that’s personal, dated, and closed the moment I write it fails all three on purpose, so it stays exactly where Carroll put it, unread by anyone else, human or AI.
A note that’s an idea I’ll want back, findable by topic instead of by day, passes the test and gets pulled out into something more durable.
This is what I call a structured note, filed by what it is rather than when I happened to think it.
That’s also where my tool choices start making sense instead of looking arbitrary.
The notebook stays paper, on purpose. It’s fast, it has no sync delay, and it never asks me to decide anything before I’m ready to.
The structured notes live as plain markdown files I control, not in a fancy proprietary app or format.
(If you don’t know what markdown files are, they are simply text files that have simple formatting markups. It is the most durable and machine-readable format.)
I draft and edit in Obsidian, because it’s really just an interface for the text files. I can move and manipulate my markdown files without working with a third party.
And finally, I use Claude to help maintain the structure once it exists. AI agents help me flag when a tag has drifted, when a note’s type doesn’t match its content, or when something’s been sitting unclassified too long.
(You’re not tied to any of these tools if you are building a knowledge base in Markdown. More on that to come as well.)
Each tool is doing one job, in one layer, and none of them is trying to be the single place everything lives.
The notebook already is that place where the first draft of everything exists.
The five jobs a note can do
You may still not be sure what I mean by information typing beyond bullet journal’s simple bullets.
I’ve written about this framework in more depth before, in Reading with Information Types and What Information Actually Is, but here’s the short version that will get you thinking about what kinds of information are in your knowledge base (not just where).
When something graduates out of the notebook, I don’t just decide it’s worth keeping. I decide what job it’s going to do for me later, because that’s what determines how it gets written and where it lives.
There are five jobs a piece of writing can do, and almost everything I’ve ever wanted to save falls into one of them:
A concept explains what something is or why it matters ... the kind of thing you read once to understand.
---
title: What a structured note is
type: Concept
topic: personal knowledge management
---
A structured note is a note typed by the job it does, not the day it was written.
A reference is a fact you look up and move on from ... a number, a name, a definition you’d never read start to finish.
---
title: Obsidian
type: Reference
topic: tools
---
Local markdown editor. No built-in AI layer. My "human interface" for drafting and editing.
A principle is a rule you can follow or break...a guideline, a standard, a “do this, not that.”
---
title: Type and content must match
type: Principle
topic: note maintenance
---
Never let a note's type and its content disagree. If you catch one, fix it before moving on.
A process describes how something happens, when you’re watching it unfold rather than doing it yourself.
---
title: How a note graduates
type: Process
topic: bullet journal workflow
---
A note gets written, sits in the notebook, and either closes for good or gets flagged to graduate.
A task is a set of steps you actually perform, in order, to get something done.
---
title: Graduating a note
type: Task
topic: bullet journal workflow
---
1. Reread the note.
2. Decide if it's settled.
3. Retype it.
4. File it by topic, not by date.
The block above each example is metadata. It’s the advanced version of this move. You don’t need it to get the benefit of typing your notes.
But once you’ve been doing this a while, tagging a note with its type and topic directly is what lets you find it later without remembering a single word of what you wrote.
You’re searching the label. No more guessing at the content.
You can also add context there for AI which helps it use your knowledge better.
Naming the type tells me the shape it needs. A table. A rule. A sequence. A short piece of prose. No more guessing.
There are more types that I’m exploring, but these are the basic ones serve as the core to any knowledge base.
Sounds like a lot of work ...
It isn’t, most days, but it’s worth being honest about why I bothered building it, and the honest answer has changed in the last few years.
I’ve been building a personal knowledge base that an AI assistant helps me maintain, and typing turns out to matter even more.
When I browse my own notes, I can tolerate some mess. I remember roughly what I meant, even when the label’s wrong.
An AI searching the same notes doesn’t have that memory to fall back on. It only finds what it’s told to look for, and untyped, undifferentiated notes give it nothing to search against except raw text and hope.
If the pattern happens to match, it might still work, but it’s much more random than you’d want.
If a note is typed, an AI assistant can tell the difference between a fact I’m citing and an idea I’m still testing, without me having to explain it every time I ask.
So if you plan on integrating AI into your knowledge base, it’s worth the work. But it’s one payoff among several, and I’d have kept doing this even without it.
A typed system is faster for me to search six months later, when I’ve forgotten the exact words I used but still remember what kind of thing I was writing.
It’s easier to hand off to a student, a collaborator, or future-me, who can open a note and know what to do with it without reading the whole thing first.
And it scales as my work grows.
Carroll built a system that already knew this intuitively, years before anyone needed to worry about what an AI could and couldn’t read.
That’s the irony, I suppose. The paper notebook is about as close to a perfect PKM as you can get, because it never tried to do all three jobs itself.
Next, I’ll be sharing how I’m building my local knowledge base of markdown files and how I’m developing the workflows that maintain the system.