The Knowledge Layer Problem: Why Capture Isn’t the Hard Part

Tribal knowledge is what an organization knows that none of its systems do. Closing that gap is most of what I work on. It has also become the thing everyone wants to talk about: architecture forums, tech summits, boardrooms looking for market advantage.

The solution folks seem to reach for is to record the floor meetings. Transcribe the technician notes. Interview the veterans. Feed the transcript blobs, the hours of audio, the PDF exports of notebook scans into a large language model, and put a chat interface on top.

Deploy an AI new hires can ask questions of when their supervisor isn’t available. That one’s mostly fine. A new hire is close enough to the work to notice when an answer is wrong, and the cost of being wrong is a follow-up question.

Then it grows. Project archives go in: closed initiatives, committee threads, the decisions nobody wanted to lose. Now someone can query a project they were never on. They get an answer, and there’s nobody in the room who was there to say “that came up, but we didn’t do it.”

Then it reaches the top. An executive queries across all of it, and what comes back reads like a finished take on a problem. It isn’t. It’s the raw material a finished take gets built from. The false starts, the walk-backs, the version of a thought before anyone did the work of turning it into a position. That work is real. Removing the layer that did it doesn’t remove the need for it. It just means the raw material arrives as if someone already had.

Even more dangerous: feeding it into risk registers and accountability domains, where a conversation about what a commitment might look like gets treated as the commitment itself. “We were kicking around doing X” becomes “we agreed to do X.”

The instinct behind these projects is that the hard part is capture. Get the knowledge out of people’s heads and into a system, and the AI will handle the rest.

But what gets captured isn’t knowledge, it’s language, and language is just meaning applied to a moment.

Meaning doesn’t hold still. Language evolves. Organizations mutate around it. A transcript freezes language at the instant it was spoken. Knowledge doesn’t freeze as easily.

The same failure shows up everywhere, but it isn’t the same failure.

In committee work it’s drift. A discussion about what a commitment might look like comes back later as the commitment. Nobody lied. The transcript just doesn’t mark the difference between a thought and a decision, and there’s nothing in it for a model to infer one from.

In compliance it’s staleness. The control was accurate in 2019. Nothing in the record says it stopped being accurate, because records don’t have a mechanism for that. Someone has to.

On the floor the knowledge was never language to begin with. A machine sounds different before a bearing goes. An operator can tell you that, and you can record them telling you, and the recording still isn’t the thing.

In software it’s the reasoning. The code works. The constraint that shaped it is gone, so the next person either preserves it by accident or breaks it by accident.

Four different failures, one shared cause: none of these systems were built to hold the thing that was actually worth keeping.

Why capture alone isn’t enough

A transcript is not knowledge. It’s a recording of someone talking about knowledge. The distinction matters because knowledge, in the sense that makes it useful to an AI, requires several properties that transcripts don’t have.

It has to have a shape. A schema. Enough structure that similar pieces of information sit in similar places and can be compared, aggregated, or reasoned across. Transcripts have narrative structure but no informational structure. A veteran assembly worker describes a failure mode in the middle of a story about a colleague who retired in 2003. The AI can retrieve the description but can’t relate it to other failure modes described in other transcripts. It can find the passage. It can’t map the terrain.

It has to have ownership. Someone has to be responsible for whether a piece of knowledge is still true. Machines get replaced. Procedures get updated. Regulations change. There’s no mechanism in a recording for marking a belief as superseded when it becomes false. Capture without ownership produces content that decays faster than it accumulates.

It has to have an update contract. A promise about how the knowledge stays current. Not a vague intention that someone will get around to updating things. A specific commitment about who does the updating, what triggers a review, and how the update propagates. Transcripts have no update contract. Once they’re recorded, they sit unchanged while the world around them moves. Six months later, the AI is retrieving fragments of a reality that no longer exists.

Without these properties, what you’ve built isn’t a knowledge system. It’s a search engine over stale audio. The AI can find things but can’t tell you which of them to trust, when they were last true, or how they relate to each other.

What this means for the tooling

The obvious answer is to give the AI more context. Feed it the documentation. Feed it the code. Feed it the conversations. The vendor recommendation, then and now, is some version of vector databases and embedding-based retrieval. Take everything the organization has, chunk it, embed it, retrieve similar fragments at inference time.

That’s the same capture-first instinct wearing better tooling. The content is still unstructured. There’s still no ownership model. There’s still no update contract. The retrieval gets better and the underlying problem doesn’t move.

Which suggests the fix runs the other way. Instead of capturing everything and hoping retrieval finds the right fragment, curate less with far more structure. Instead of embeddings, files. Instead of semantic search, routed lookup. Instead of scraping documentation into a database, treat the knowledge itself as source code.

I’ve been calling that Context-as-Code. What it looks like in practice, and the discipline it borrows from software engineering, is what I’ll write about next.

Capture is easy. Structure is hard.