The Moments You're Too Busy to Write Down
The most important decisions in your working life are systematically absent from your knowledge base. That's not a discipline problem. It's structural.
You just had the conversation. The one that changed how you understood the problem, or why you made the call you did, or what the other person was actually asking for. You walked out thinking you should write it down. You didn't. Another meeting, then another. Three weeks later you're trying to reconstruct what was said and why — and the memory feels solid. Vivid, complete, confident. It probably isn't.
In 1986, Ulric Neisser asked a group of college students to describe how they heard the news about the Challenger disaster, the morning after it happened. Two and a half years later, he asked them again. A quarter of them described completely different scenarios — wrong people, wrong places, wrong circumstances. The mean accuracy score was 2.95 out of 7. Confidence remained high throughout.
The brain flags emotionally charged moments with a feeling of certainty. That feeling is not correlated with accuracy. It's precisely what prevents you from writing things down in the moment — because it tells you that you won't need to.
The inverse documentation problem
There's a consistent pattern in how knowledge actually accumulates in a personal knowledge base, versus how it should.
The low-stakes, low-urgency things get written down. The idea that came to you on a quiet Tuesday afternoon. The meeting summary where nothing significant happened. The research note from an article you read before going to sleep. These get documented because you had time, and the stakes were low enough that writing felt productive rather than like an interruption.
What doesn't get documented: the conversation where someone told you why they were really leaving. The decision you made under time pressure when three constraints collided and you chose the one that seemed right. The realization at the end of a difficult month that changed how you saw a whole class of problems. These moments are too alive to write about while they're happening, and too recent to reconstruct cleanly once they're done.
By the time the meeting ends and the calendar moves and you finally sit down to write, you're not reconstructing the decision. You're constructing a story about it. The alternatives you didn't consider are gone. The uncertainty resolves into the outcome. The reasoning gets replaced by rationalization — not because you're being dishonest, but because memory is reconstructive. That's how it works. Neisser found the same pattern in students recalling the biggest news event of the decade.
The result: a knowledge base full of the forgettable and systematically empty of the consequential. Not because people lack discipline, but because the moment of maximum importance coincides with the moment of minimum recording capacity.
What structured capture is actually for
Most writing about personal knowledge management focuses on retrieval — making information findable once it's been written. The prior problem, which gets less attention, is the gap between the moments that actually shaped your decisions and what ended up on the page.
One partial answer: if you can't write the important thing during the moment, you need a structure that makes reconstruction faster afterward, and that forces you to capture the parts memory will smooth over. Not a free-form note that starts with "what happened" and ends wherever your attention drifts. Something that asks you specific questions: what were the actual options? What did you choose? What were you uncertain about at the time?
Michael Nygard's Architecture Decision Records — originally designed for software teams — work on this principle. Context, decision, consequences, separated into fields. The structure forces you to document the parts hindsight would otherwise replace. Not because the format is special, but because blank fields ask questions that blank pages don't.
The same principle applies to a person record, a project note, a captured preference. When you write "talked to Ana" into a free-form document, you're writing for yourself-now, who still has the context. When you write to a record with a schema — a name, a date, an outcome field — you're writing for yourself-later, who won't. The structure presupposes the reader who wasn't in the room.
None of this fixes Neisser's finding entirely. Memory is reconstructive regardless of what you write in. But there's a difference between reconstructing into a structured frame — what were the alternatives, what was I uncertain about — and reconstructing into a blank document that defaults to the most coherent narrative available. The blank document almost always produces the coherent story. The schema produces something closer to the messy original.
The test that actually matters
The right question to ask of a knowledge system isn't whether it handles well-formed notes efficiently. Most tools do that adequately. The real test is what happens to the moments you didn't have time to document: the conversation in the hallway, the decision made in the third hour of a difficult meeting, the realization at the end of a hard project that you've never quite found language for.
A knowledge base that captures only what you were already planning to write down is a filing cabinet for your mundane moments. What the important ones need is something different — a format with enough structure that reconstruction, when it finally happens hours or days later, lands somewhere more accurate than a confident story that may or may not resemble what actually occurred.
Not a cure for Neisser's problem. Just a slightly better form of it.
Asgeir Albretsen is the founder of Harbor.