The Goldilocks problem nobody talks about
You already know that big, tangled ideas need to be broken apart. Lesson 23 covered that — decomposition reveals hidden complexity. But decomposition alone doesn't tell you when to stop splitting. And this is where most people go wrong.
Split too little and you have compound notes — bloated containers that fuse multiple claims, multiple contexts, multiple concerns into a single entry. They're hard to link, hard to reuse, and hard to challenge because you can't disagree with part of a compound note without engaging the whole thing.
Split too much and you have fragments — isolated shards that carry no meaning on their own. A note that reads "important for retention" is useless six months later. Retention of what? Important how? For whom? You've decomposed past the point of meaning. You've created noise.
The smallest useful unit sits between these extremes. It's the level of granularity where each piece is independently meaningful — small enough to be precise, large enough to be self-contained. Finding this level is not a mechanical process. It's a perceptual skill, and developing it changes how you think about knowledge, software, writing, and every other domain where structure matters.
What "independently meaningful" actually means
Andy Matuschak, whose public working notes remain one of the most rigorous experiments in personal knowledge management, frames the principle directly: "Evergreen notes should be atomic." His reasoning is structural, not aesthetic. If a note is too broad, you won't notice when you encounter a new idea about one of the notions buried inside it, and links to that note become muddied. If notes are too fragmented, your link network fragments too, making connections harder to see.
The test for atomicity is simple: can this note stand alone? Can someone — including your future self — read it without needing three other notes beside it to understand what it means? If yes, you've found a useful unit. If not, you've either split too far or you haven't split far enough.
Matuschak explicitly compares this to the software engineering principle of separation of concerns — the idea that modules should be "about" one thing so they're more easily reusable. He even argues that evergreen note titles are like APIs: they define the interface through which other ideas connect. A note titled "Customer retention depends on onboarding speed" is a clear API. A note titled "Thoughts on growth" is a leaky abstraction that could mean anything.
This isn't a metaphor. Knowledge units and software modules face the same structural tension. Too coarse and they become entangled. Too fine and the overhead of managing connections exceeds the value of the units themselves.
The chess master's chunk: expertise changes the unit
What counts as a "smallest useful unit" is not fixed. It depends on who's doing the perceiving.
In 1973, William Chase and Herbert Simon published their landmark study on chess expertise, "Perception in Chess." They showed chess masters something that surprised the field: when given five seconds to view a board from a real game, masters could reproduce the positions of roughly 20 pieces while novices recalled about 4. But when the pieces were placed randomly — in positions that couldn't arise in real play — masters performed no better than beginners.
The explanation was chunking. Masters didn't have better raw memory. They perceived the board in larger meaningful units — a kingside pawn structure, a fianchettoed bishop pattern, a castled position. Each "chunk" was a single perceptual unit for the expert but a collection of unrelated pieces for the novice. The master's smallest useful unit was bigger because their expertise made larger patterns independently meaningful.
Chase and Simon measured this directly. They recorded players during recall and noticed a consistent pattern: subjects would place several pieces rapidly, then pause for two or more seconds, then place another burst. Those pauses marked chunk boundaries — the seams between one meaningful unit and the next. Masters had fewer, larger chunks. Novices had more, smaller ones. Same board, different units.
The implication for knowledge work is direct: as your expertise in a domain grows, your smallest useful unit changes. A beginner's atomic note about "how HTTP works" might need to be a paragraph. An experienced engineer's atomic note can be "HTTP is stateless" — three words that carry an entire web of implications. Both are the smallest useful unit for their respective contexts. The unit isn't defined by word count. It's defined by the meaning the reader can extract.
The information-theoretic floor
There's a formal way to think about the smallest useful unit. In information theory, the Minimum Description Length (MDL) principle states that the best model of your data is the shortest description that still captures its regularities. Compress too much and you lose meaningful patterns. Compress too little and you're carrying noise.
The Kolmogorov complexity of a string — the length of the shortest program that can produce it — represents a theoretical lower bound on compression. You can't describe the data in fewer symbols without losing information. In practice, Kolmogorov complexity is uncomputable, but the principle it encodes is actionable: there exists a floor below which further compression destroys meaning.
Applied to knowledge: every idea has a minimum description length. "Customer retention depends on onboarding speed in SaaS products because early activation predicts 90-day survival" can be compressed to "onboarding drives retention." That's still meaningful — it's a useful unit. Compress further to "onboarding" and you've crossed the floor. The word alone carries no claim, no relationship, no actionable insight. You've eliminated the signal along with the noise.
The MDL principle also explains why the right granularity feels like discovery rather than choice. When you find the smallest useful unit, it has the quality of inevitability — this is where the idea naturally separates. You're not imposing structure. You're detecting the structure that was already there, the way a sculptor claims to find the statue inside the marble.
How Agile teams find the smallest valuable increment
Software teams have been working this problem for two decades under a different name. In Agile development, the INVEST criteria define what makes a good user story: Independent, Negotiable, Valuable, Estimable, Small, and Testable. The "S" and the "V" encode the same tension we've been discussing — small, but still valuable.
A user story that says "Build the entire checkout flow" is too big. A story that says "Add a border to the submit button" is too small — it's not independently valuable. The smallest useful story is something like "As a customer, I can enter my shipping address and see the estimated delivery date." That's small enough to build in a sprint, large enough to deliver value a user can see and validate.
Bill Wake, who coined the INVEST acronym, framed it as a negotiation between granularity and completeness. Teams that split stories too aggressively create what practitioners call "horizontal slices" — work that touches only one architectural layer (just the database, just the UI) and delivers nothing usable on its own. The antidote is "vertical slices" — thin but complete increments that cut through every layer and produce something a user can actually interact with.
The parallel to knowledge management is precise. A note that captures only one layer of an idea — just the claim without the evidence, or just the evidence without the implication — is a horizontal slice. It can't stand alone. A note that includes a complete thought — claim, key evidence, implication — is a vertical slice. It's the smallest useful unit because it's the smallest thing that delivers complete meaning.
Progressive summarization: finding the unit inside the source
Tiago Forte's Progressive Summarization technique approaches the smallest useful unit from the opposite direction. Instead of building up from fragments, you compress down from sources.
The technique works in layers. Layer 0 is the original full-length source. Layer 1 is the passages you initially captured — anything that felt insightful or useful. Layer 2 is the first round of true summarization: you bold only the key sentences that represent the core ideas. Layer 3 narrows further — you highlight the critical phrases within the bolded passages. Layer 4, for the rare sources that warrant it, is your own remix: you rewrite the core insight in your own words.
Each layer is a compression step. And the skill of Progressive Summarization is knowing when to stop compressing. Forte frames it as structuring your attentional environment — creating signposts that tell your future self where to focus. The final highlighted passage or remixed note is, effectively, the smallest useful unit of that source: the minimum amount of text that still carries the insight you originally found valuable.
What makes this powerful is that the layers are reversible. If you ever need more context, you can "zoom out" to the previous layer. The smallest useful unit isn't a permanent reduction. It's a lens setting — you choose the level of granularity appropriate for your current purpose, with the option to change it.
AI and the granularity problem
If you use AI for retrieval — and increasingly, every knowledge worker does whether they realize it or not — the smallest useful unit becomes a technical constraint, not just a cognitive preference.
Retrieval-Augmented Generation (RAG) systems work by splitting your documents into chunks, converting those chunks into numerical embeddings, and then finding the most relevant chunks when you ask a question. The quality of retrieval depends directly on chunk granularity.
Research from 2024 and 2025 has converged on a finding that mirrors the human cognition story exactly: the optimal chunk size depends on the type of question being asked. Factual queries — "What was the Q3 revenue?" — perform best with small chunks of 256 to 512 tokens. Analytical queries — "What drove the decline in customer satisfaction?" — require larger chunks of 1,024 tokens or more because the answer depends on context that spans multiple sentences.
NVIDIA's 2024 benchmark tested seven chunking strategies across five datasets and found that no single granularity dominates. The practical recommendation that has emerged is to start with chunks of 400 to 512 tokens with 10 to 20 percent overlap, then adjust based on retrieval quality metrics. Too small and the chunks lose context — the embedding doesn't capture enough meaning to match the right query. Too large and the chunks contain noise — irrelevant information that dilutes the semantic signal.
This is the information-theoretic floor made operational. When an AI system retrieves a chunk that's too small, it's below the minimum description length — the chunk can't carry its meaning without its neighbors. When it retrieves a chunk that's too big, it's above the useful compression level — it's carrying information the query didn't ask for.
The implication for your personal knowledge system is direct. Every note you write is a potential retrieval unit — whether retrieved by your own memory, a search function, or an AI assistant. Notes at the right granularity get found and used. Notes that are too big match too many queries imprecisely. Notes that are too small match nothing because they don't contain enough signal to connect to.
How to calibrate your own granularity threshold
Finding the smallest useful unit is a skill, not a formula. But there are reliable heuristics:
The title test. Can you give this note a specific, descriptive title? "Customer retention depends on onboarding speed" passes. "Various thoughts about growth" fails. If you can't title it precisely, it probably contains more than one idea.
The link test. When you try to link this note to other notes, do all the links feel relevant to the entire note? Or do some links only connect to part of it? If links connect to different parts, the note contains multiple units waiting to be separated.
The challenge test. Can someone disagree with this note as a whole? If the note contains one claim, disagreement targets the whole thing. If it contains three claims, someone might agree with two and dispute one — which means you've bundled ideas that should be independent.
The reuse test. Could this note be useful in a completely different project or context? Atomic notes are reusable because they're about one thing. Compound notes are context-bound because they're about one situation that happens to involve multiple things.
None of these tests give you a binary answer. They give you signal. Over time, you develop an intuition — a feel for where ideas naturally separate, the way an experienced woodworker feels where the grain wants to split.
The connection to what comes next
Finding the smallest useful unit is the skill. But knowing why you need it — that comes from understanding what happens when you don't have it. Compound ideas don't just resist decomposition. They actively hide their internal structure. A note that bundles three claims looks like one idea. A strategy that fuses four assumptions presents as a single plan. And because the components are invisible, so are the dependencies between them.
That's where we go next. In Compound ideas hide dependencies, you'll see how ideas that seem simple often contain multiple assumptions bundled together — and why those hidden bundles are where the most dangerous failures live.