Someone says: "we need to capture this knowledge before the expert leaves." Everyone nods. A wiki gets built, an exit interview gets recorded, a folder of documents gets frozen in a shared drive. Six months later the expert is gone and the folder is useless — technically present, functionally inert. The usual diagnosis is that the capture wasn't thorough enough. Not enough was written down. The wrong things were prioritized. Do it again, better, more completely next time.
I think the diagnosis is wrong, and it's wrong in a specific, correctable way: the capture was never storing what people thought it was storing.
The accumulation model
Call it the accumulation model of knowledge transfer: expertise is a quantity, held by a person, extractable into a document, transferable by reading. Under this model, failure is a coverage problem. You didn't get enough of it down. The fix is always "more" — more interviews, more detail, more structure, a better wiki, a better tagging system.
This model has an obvious appeal. It's how storage works for everything else — files, inventory, money. And it isn't crazy; some knowledge really is closer to a fact-list, and fact-lists transfer fine as documents. But for the kind of knowledge people actually worry about losing — the expert's judgment, the sense of when something's about to break, the thing that takes fifteen years to develop — the accumulation model has a bad track record. The documents get written. The documents don't work. And the diagnosis loops back to "not enough was captured," which produces more documents that also don't work.
The collision model
Here's a different account, developed originally about archives and publication but that generalizes past both. An archive — a library, an institutional wiki, a folder of an expert's notes — doesn't primarily work by storing the insight. It works by storing the conditions for re-deriving the insight under pressure. You don't read the expert's troubleshooting notes and receive their judgment. You read them while something is actually broken, under time pressure, with a half-formed hypothesis already active in your head — and the notes collide with that live problem and produce something functionally equivalent to the judgment you were trying to capture. Not the same thing. A re-derivation, occasioned by the encounter.
If this is right, what the exit interview should be optimizing for isn't completeness of coverage. It's the setup for a future collision: what will someone be holding in their head, under what kind of pressure, when they open this document — and does the document give that collision somewhere useful to land?
This reframes what "knowledge transfer" was ever accomplishing when it worked. Teaching, similarly, doesn't obviously function as transmission — a fact moved intact from one head to another. It functions as collision-positioning: the teacher sets up a situation (a problem, a text, a provocation) engineered to produce a re-encounter, and the student's re-derivation under that engineered pressure is what actually sticks, not the transmitted content itself. The lecture that "opens a field" for a student doesn't hand them the field's discoveries. It creates the conditions under which they go make some.
Different failure modes
The payoff of getting the model right isn't philosophical tidiness. It's that the two models predict different failures, and you can only fix the failure you've correctly diagnosed.
Under the accumulation model, you fail by not storing enough. The fix is always additive: more documentation, more detail, more completeness.
Under the collision model, you fail by not creating conditions for pressure. A document can be extremely complete and still fail completely, because nobody ever opens it while holding a live, half-formed problem that needs exactly what's in it. Completeness was never the bottleneck. Occasion was.
This is why so much institutional-knowledge capture feels like throwing effort at the wrong lever. The wiki gets more thorough and the retention problem doesn't move, because thoroughness was answering a question nobody was actually asking. The real question — under what conditions will a future person, holding a real problem, collide with this? — usually has almost nothing to do with how much is written down and almost everything to do with whether the document is positioned where the pressure will actually occur: linked from the error message, referenced in the onboarding problem set someone is forced to actually struggle with, sitting exactly where the next outage will make someone go looking.
What changes if you believe this
Practically: stop asking "did we capture enough" and start asking "where will the pressure be, and is anything positioned to meet it there." An exit interview that produces a beautifully complete document nobody will ever be under pressure to read is a worse outcome than a rougher document sitting exactly where the next crisis will surface it. A curriculum organized around comprehensive coverage of a field is optimizing the wrong variable if what actually produces understanding is a smaller number of well-positioned collisions — problems hard enough, and timed well enough, to force real re-derivation.
None of this means accumulation-as-storage is worthless — some knowledge genuinely is a fact-list, and fact-lists benefit from completeness in the ordinary way. The claim is narrower: for the specific class of knowledge people invoke "we need to capture this before it walks out the door" about — judgment, pattern-recognition, the fifteen-years-in kind of expertise — accumulation was never the mechanism, even when it appeared to work. It worked, when it worked, because someone later collided with the material under the right pressure. The storage was doing collision-infrastructure's job under an accumulation description, and the description is what's been misleading everyone about which lever to pull.