The map that destroyed an empire
In 1946, Jorge Luis Borges published a one-paragraph parable about an empire whose cartographers grew so obsessed with accuracy that they built a map the same size as the territory it described. Point for point, the map matched the empire. And it was, of course, completely useless. Subsequent generations abandoned it, leaving its tattered fragments to rot in the western deserts, "inhabited by animals and beggars."
The story is fiction. The mistake it describes is real — and people make it every day with their notes, their plans, and their thinking systems.
The instinct is understandable. When you sit down to decompose a book, a meeting, or an idea into notes, it feels like there should be a correct level of detail. Some natural joint in the material where the atoms live, waiting to be discovered. Break it down to that level and you've done the work properly. Miss it and you've done it wrong.
That instinct is the enemy. Note granularity is not a property of the material. It is a property of your purpose. And confusing the two will paralyze your entire system.
Every system can be described at multiple levels
David Marr, the neuroscientist who transformed how we understand vision, proposed in 1982 that any information-processing system must be understood at three distinct levels: the computational level (what problem is being solved and why), the algorithmic level (what procedure solves it), and the implementational level (what physical mechanism carries out that procedure). A cash register can be described as "a device that computes correct change" (computational), "a system that subtracts the price from the amount tendered" (algorithmic), or "a circuit board with specific transistor arrangements" (implementational).
None of these descriptions is more correct than the others. Each is the right level of analysis for a different question. If you want to know whether the machine is solving the right problem, you work at the computational level. If you want to debug a calculation error, you drop to the algorithmic level. If the machine is physically broken, you go to implementation.
Marr's insight was not just about neuroscience. It was about the nature of description itself: the level of analysis you choose determines what you can see. And there is no neutral, purpose-free level from which you see everything.
The same principle operates in cartography. The International Cartographic Association defines generalization as "the selection and simplified representation of detail appropriate to the scale and/or the purpose of a map." A road map and a topographic map of the same county use different granularities — not because one is more accurate, but because they serve different needs. The road map suppresses elevation contours because drivers don't need them. The topographic map suppresses minor roads because hikers don't need them. Each map is correct. Each is a deliberate compression chosen for a purpose.
This is not an edge case. It is the nature of all representation. You cannot describe anything at all levels of detail simultaneously. To represent is to choose a grain size. And that choice is yours.
Purpose determines grain size
In software engineering, this principle gets tested every two weeks. Agile teams decompose work into user stories, and those stories need to be small enough to complete within a sprint — typically one to three days of work. The INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable) provide a framework, but notice what drives the "Small" criterion: it is sprint capacity, not some inherent property of the feature.
A feature like "user authentication" could be one story or twenty. A team with a two-week sprint and four developers will split it differently than a team with a one-week sprint and two developers. The stories are not discovered at the right size. They are cut to fit the team's purpose and capacity. As the Humanizing Work guide to story splitting puts it, the goal is vertical slices — thin, end-to-end pieces that each deliver value — sized to what the team can ship and learn from.
Ontology engineering faces the same problem in a more formal setting. When knowledge engineers build classification systems — deciding how to categorize diseases, or legal concepts, or biological species — they must decide how fine-grained to make their categories. This is known as the "ontological commitment" problem: there is no objectively correct level of categorical detail. As Tom Gruber articulated in his foundational work on ontology design at Stanford, the right level of granularity depends on the questions you need the ontology to answer. A medical ontology for billing codes needs different categories than one for clinical research, even when they describe the same diseases.
The pattern is always the same. Grain size is downstream of purpose. The material doesn't dictate it. Your use case does.
The cognitive cost of wrong grain size
This is not just an abstract design principle. Getting granularity wrong has measurable cognitive consequences.
Jeroen van Merrienboer's Four-Component Instructional Design model (4C/ID), developed over three decades of research into complex skill acquisition, demonstrates that learning tasks must be calibrated to the right level of complexity. Too fine-grained and learners drown in disconnected fragments — they can recite details but cannot coordinate them into coherent performance. Too coarse-grained and learners face excessive cognitive load — the whole task overwhelms working memory before any structure can form.
The 4C/ID solution is not to find the "right" grain size once and freeze it. It is to start with simplified whole tasks and progressively increase complexity. The grain size changes as the learner's capacity changes. It is adaptive, not fixed.
The same dynamic plays out in note-taking. Christian Tietze at zettelkasten.de frames atomic notes as a "processing direction" — you aim for one knowledge building block per note, but the size of that building block depends on what you are building. A note about "the benefits of bootstrapping a business" is too coarse if you need to reason about specific tradeoffs. But it is perfectly appropriate if you are building a high-level map of entrepreneurship strategies. The grain size that produces useful atoms for one purpose produces useless dust for another.
Tiago Forte's progressive summarization addresses this from the opposite direction. Instead of choosing one grain size at capture time, you layer increasingly compressed summaries onto the same source material. The original text stays intact. Bold highlights mark what matters most. A second layer of highlights marks the highlights. An executive summary compresses further. Each layer is a different granularity of the same material, and you reach for whichever layer matches what you need right now.
The underlying lesson: if you are spending more than a few seconds agonizing over whether a note is "atomic enough," you have mistaken a design choice for a discovery problem. Name your purpose. Cut to fit. Move on.
Resolution is always a tradeoff
In medical imaging, radiologists choose scan resolution based on clinical need. A chest X-ray screening for tuberculosis uses different resolution parameters than a CT scan investigating a suspicious pulmonary nodule. Research published in Radiology: Artificial Intelligence found that some findings — like emphysema and small nodules — benefit significantly from higher image resolution, while others — like large thoracic masses — show no performance improvement with increased detail. More pixels is not categorically better. It is better only when the diagnostic question demands it.
The computational cost of higher resolution is not trivial. Medical imaging AI models routinely downsample images to fractions of their native resolution — AlexNet famously used 227x227 pixel inputs — because the full resolution would overwhelm both memory and processing time without improving accuracy for the task at hand. The engineering decision is always: what resolution does this question require?
Your knowledge base works the same way. Every note, every decomposition, every categorization is a resolution choice. Higher resolution (finer grain) costs more to create, more to maintain, and more to search. It is worth that cost only when your retrieval questions demand it. A project planning system needs different resolution than a philosophical reading journal. A reference library of technical procedures needs different resolution than a collection of creative writing prompts.
The failure mode is treating resolution as a virtue rather than a tool. More detail is not more correct. It is more expensive — and often less useful.
AI and adaptive granularity
This is where the principle becomes operationally urgent. If you use AI — retrieval-augmented generation, semantic search, a "second brain" with an LLM interface — then granularity is not just a personal preference. It is an engineering parameter that determines whether your system works.
Recent research on RAG (retrieval-augmented generation) systems reveals a structural tension: semantic matching works best with small chunks of 100 to 256 tokens, because tight, focused text produces clean embeddings. But context understanding requires larger chunks of 1,024 or more tokens, because the LLM needs enough surrounding material to reason about the retrieved information. A 2024 paper on Mix-of-Granularity (MoG) proposes dynamically routing queries to different chunk sizes based on what the question demands — using a router to select whether a given query needs fine-grained keyword-level retrieval or coarse-grained passage-level context.
The practical takeaway: if you dump all your notes into a vector database at a single granularity, some queries will work beautifully and others will fail. Queries that need precise factual retrieval ("What is the half-life of caffeine?") want small, tightly scoped chunks. Queries that need contextual reasoning ("How does caffeine metabolism interact with sleep architecture?") want larger, more narrative chunks. The same knowledge base needs to support multiple grain sizes — or it serves only one kind of question well.
This mirrors what Marr described for cognitive systems and what cartographers have known for centuries: there is no single resolution that serves all purposes. The systems that work best are the ones that let you zoom in and out — adjusting granularity to match the question you are asking right now.
If you are building a personal knowledge system that will interact with AI, you have a design choice to make. Not "what is the right note size?" but "what purposes will I query this system for, and what granularities do those purposes require?" That is a design question, not a discovery question. And answering it well is the difference between a system that retrieves useful context and one that returns noise.
Granularity as a practice, not a setting
The temptation is to set a granularity rule once — "all my notes will be exactly one idea each" — and never revisit it. This is the same mistake as choosing one map scale for all terrain.
Instead, treat granularity as a practice. Before you decompose anything, state your purpose. "I am breaking this book down so I can write an essay next month." "I am decomposing this meeting so I can brief my team in fifteen minutes." "I am atomizing this research paper so I can find specific claims during future literature reviews." Each purpose implies a different grain size. Each is valid.
When your purpose changes, re-cut. The notes you made for essay writing may be too coarse for a detailed technical comparison. The atoms you created for retrieval may be too fine for a high-level strategy discussion. This is not failure. It is the system working as designed. Granularity is a living parameter, adjusted as your needs evolve.
In the previous lesson, you learned that context must travel with the atom so that each note can be understood on its own. Now add a second principle: the atom itself is not a fixed size. You decide how large or small it is based on what you are building. Context makes each atom self-sufficient. Purpose makes each atom the right size.
With both principles in hand, you are ready for something that changes how you think about your entire note system: questions are atoms too. Not just answers, not just claims — the questions themselves deserve the same atomic treatment. That is where we go next.