← All posts
23 August 2025

The Map of What You Don't Know

Most knowledge bases show you what you captured. The more interesting design problem is making visible what you didn't.

Three years ago I spent six weeks building a feature that never shipped. I kept notes throughout — architecture decisions, meeting summaries, open questions. When I came back to that project folder last month, the notes looked thorough. Fourteen documents, well-organized, with timestamps and links. Completely silent on the one thing I needed: why we killed it.

Not the technical reason. I had that. The actual reason — the conversation where someone changed their mind, the priority call, the thing that made it feel obviously wrong — was nowhere. The notes captured what happened; they missed why it mattered.

George Loewenstein published a theory of curiosity in 1994 that I think applies here. His claim: curiosity arises when you perceive a gap in your knowledge. Not from complete ignorance — you can't be curious about something you know nothing about. Not from complete knowledge either. Curiosity lives in the middle: you know enough to know something's missing.

Nobody seems to apply this to knowledge management. But the implication is specific: a good knowledge base should make gaps visible. Not just store what you know. Show you what you don't.

Most notes look complete when they're not

The structural problem with unstructured text is that it can't have visible gaps. A document doesn't have fields. It can't be incomplete in a way the system detects — only in a way you notice when you read it closely and realize something's off.

This is why notes from three years ago feel unusable. Not because the information decayed. Because the information was never complete, and nothing made that obvious at the time.

Darwin's notebooks — dozens of them, from the Beagle voyage through his final experiments at Down House — are interesting partly because of how explicitly he tracked his own uncertainty. He marked unresolved observations differently from confirmed ones. His "Experimental Book," begun in 1855, is full of questions he hadn't answered yet, sitting alongside the ones he had. The open question wasn't incomplete thinking; it was the thinking. The gap was the point.

Most notes apps make no space for that distinction. Everything looks equally definitive. A confident conclusion and a half-formed guess sit in the same format, same font, same timestamp. You can't tell which is which when you come back.

Structure creates exploitable gaps

A typed entity has a schema. A schema can be incomplete in a visible way.

A task without a deadline isn't silently incomplete — it's visibly incomplete. A person record with no "last contact" date has a field that's empty. You can see it. A project with no decision log has a section that exists but contains nothing. The absence is structural, not textual. The system knows something is missing.

This is a design distinction that rarely comes up in PKM writing, which focuses almost entirely on retrieval: can you find what you saved? The more interesting question is whether your knowledge base can surface what you should have saved but didn't.

Loewenstein's research predicts that seeing an empty decision field in a project record would induce curiosity. You know there must have been a decision. You know you don't have it. Now you want it. Productive discomfort. The gap does work that a wall of prose cannot.

An unstructured note has no schema to be incomplete against. Its incompleteness is invisible until you read it carefully, realize what's missing, and have probably already forgotten why the gap matters.

The priming effect

There's a second finding from Loewenstein's work worth noting. A small amount of information dramatically increases curiosity — more than either total ignorance or complete knowledge. Partial structure is more engaging than a blank page or a dense archive.

This maps to something that's hard to explain about why some knowledge bases get used and others don't. When a knowledge base has some structure around a topic — a few connected entities, a partial decision record, linked notes that don't quite resolve — it pulls you toward completing the picture. The partial structure motivates more than the blank page or the overfull folder.

The right level of incompleteness is productive. Not enough structure and there's nothing to be curious about. Too much and there's nothing left to discover.

What the gap knows

The knowledge base as answer machine has obvious appeal. You ask; it retrieves. That's the primary pitch for AI-powered knowledge tools, and it's genuinely useful.

But there's a version that goes further: the knowledge base as a gap machine. Not a tool that answers your questions but one that surfaces the questions you forgot to ask. The decision you never recorded. The person you met and never followed up with. The project that ended without a retrospective.

Darwin's notebooks worked this way because they were explicitly structured to track the movement from hypothesis to evidence to resolution — which made the cases where that movement stopped visible. You could see where he'd gotten stuck.

Most personal knowledge bases aren't structured enough to show you where you're stuck. They show you what you captured. Getting gap-detection right — so that the shape of what you didn't capture is visible — is one of the harder design problems in personal knowledge software. And it's a problem that starts with typed entities and schemas, not better search.


Asgeir Albretsen is the founder of Harbor.

The Map of What You Don't Know: Harbor Blog | Harbor