Knowledge Debt
Every undocumented decision and lost conversation context is a shortcut. Like technical debt, knowledge debt accrues interest — paid later, repeatedly, in time you don't have.
There's a decision somewhere in your history — 18 months ago, maybe two years — where you can recall the outcome but almost nothing that led to it. At the time, the reasoning was obvious. You were surrounded by the context: the meeting, the alternatives you'd rejected, the thing someone said that tipped it. Today someone asks you to explain the call, and the answer you give is plausible. You're not sure it's accurate.
That gap — between the decision and the ability to account for it — is what I've started calling knowledge debt.
Ward Cunningham named technical debt in 1992, presenting his work on a portfolio management system at OOPSLA. The framing was precise: "Shipping first-time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite." The danger, Cunningham was careful to say, wasn't the shortcut itself. It was the interest on shortcuts that were never revisited.
Knowledge debt accrues the same way. Every decision you made without recording the reasoning, every conversation you had without noting the key conclusions, every relationship context you kept only in memory. These are shortcuts. Faster in the moment. Expensive later.
The invisible part
The difference from technical debt is that knowledge debt is almost entirely invisible while it's accumulating.
With code, the debt leaves artifacts: messy files, workarounds, the function with the comment that says "fix this later." You can look at a codebase and get a rough sense of its debt load. Knowledge debt has no such signal. The gap in your decision log doesn't show up as a gap. It's just nothing. The missing notes from a three-day offsite aren't marked as missing anywhere.
Hermann Ebbinghaus spent the years from 1880 to 1885 memorizing nonsense syllables and testing himself at various intervals. His data showed that 42% of what he'd learned was gone within 20 minutes, and roughly 79% within a month. The curve is steep early and flattens later. Decisions and contextual reasoning aren't nonsense syllables, but the mechanism is similar: the reasoning that felt obvious in the meeting fades well before you'd think to write it down.
And here's the specific way this compounds: by the time you realize you should have recorded something, it's usually too late to record it accurately. You reconstruct what seems right and file that as the original. The debt is repaid with counterfeit.
When it comes due
Knowledge debt gets called in a few recognizable situations.
The first is handoffs. You're explaining a project to someone who wasn't there — a new colleague, an incoming manager, the AI tool you've just connected to your files. The knowledge needs to travel to a reader who has no shared context, and the things you didn't bother to write down were precisely the things you assumed the reader already knew.
The second is the return. Three weeks away from a project. You come back and find your own notes slightly alien. The file says "use the v2 API" without saying why v1 was rejected. You remember there was a reason. You spend an hour figuring out whether it still applies.
The third, and increasingly common, is the AI query. An AI agent has access to your knowledge base. You ask it something contextual. It gives you a confident answer assembled from the notes you actually wrote, which are the tip of the iceberg. The confident answer is built from the visible part of the problem.
The interest rate
Cunningham's metaphor holds here too: the interest on knowledge debt isn't paid all at once. It's paid in small increments, repeatedly, each time you need the context that isn't there. A decision log entry that would have taken three minutes to write gets replaced by forty-five minutes of archaeology, spread across multiple incidents over years.
The design response isn't complicated, but it runs against how most note-taking tools work. Most tools optimize for capture speed — frictionless input, any shape, wherever. The problem isn't capture. It's the absence of any record of what kind of thing you captured, or why.
A decision record that captures context, alternatives, and reasoning at the moment of the decision doesn't just help future retrieval. It changes the quality of the decision itself — you're forced to articulate the reasoning while you're still in the context that makes it articulable. That's what Michael Nygard's Architecture Decision Records demonstrated in software teams: the benefit wasn't documentation. It was the discipline of writing while you still knew what you knew.
Knowledge debt will always exist. Some shortcuts are worth taking. The interesting design question is which parts of your knowledge have natural shape — decisions, people, preferences — and actually benefit from structured capture at input time. Those are the ones where the compound interest is highest, and where a few extra seconds at the threshold pays the clearest dividend.
Asgeir Albretsen is the founder of Harbor.