What is operating knowledge, and why your documents do not have it

Ask a COO for a copy of how the work is done, and you will get documents. SOPs, process maps, wikis, a training deck from three years ago, maybe a Notion database that someone cleaned up before a board meeting.

Then sit next to the person who actually runs that work. Watch them handle a case. Watch which field they check first, which one they ignore, which colleague they message before making the call, which exception they treat as routine and which one they escalate. None of that is in the documents. It is not even close.

That gap has a name. It is operating knowledge. And until you understand what it is and why your documents do not contain it, no amount of documentation, search, or AI is going to make the operation run better.

This post is about what operating knowledge is, why it is not in your documents, and why the gap is the reason enterprise AI keeps failing.

The simple definition

Operating knowledge is what your best people use to actually do the work. Not the version they would describe in a meeting. The real one, the one they use when a case hits their desk on a Tuesday afternoon and the system says one thing and their gut says another.

It has four parts.

Decision logic. Not "what gets approved" but why this case gets approved and a nearly identical one does not. The reason behind the decision, not just the decision itself.

Exception handling. Every process has official rules and real rules. The official rules cover the clean cases. The real rules, the ones that keep the operation from breaking, live in the expert's head. Which field is stale, which supplier quote is reliable, which escalation path actually gets a response.

Trusted sources. Which system to check first. Which report to ignore. Which colleague to call before committing to a decision. This ordering is never written down. It is accumulated over years.

Escalation reasons. The specific moments an experienced operator stops the work and asks for a human review. Not because a rule says so. Because they have seen this pattern go wrong before.

Put those four together and you have the substrate the operation actually runs on. Take any one of them away and the work breaks on real cases.

Documented knowledge vs the real process

Documented knowledge is the map. Operating knowledge is the territory.

Documentation captures what the company says should happen, the idealized workflow, the policy, the checklist. It is written for training, for compliance, for onboarding. It is designed to describe an average case to an average reader.

The real process is different. It has workarounds that evolved because the official path was too slow. It has unwritten rules about which approvals matter and which are rubber stamps. It has judgment calls that were never codified because nobody thought to codify them.

The gap between those two is where the expert lives. It is also where nearly all of the operation's value sits.

Panopto's research suggests that 42% of essential expertise lives only in employees' heads. Roughly 80% of operational processes are undocumented [Tallyfy]. Those two numbers point at the same thing from different angles. Most of what makes the operation work is not, has never been, and probably will never be captured in a document.

That is not a documentation failure. It is a documentation limit. A static document was never designed to hold decision logic, exception handling, trusted sources, and escalation reasons. It was designed to describe a workflow. Those are different jobs.

If you want to see the difference concretely: a policy manual can say "escalate to the supervisor." The expert knows the supervisor will reject it unless you frame the request a certain way, send it before 3pm on a Tuesday, and include a specific attachment that is not in the official checklist. Both statements are true. Only one of them is operating knowledge.

Why documents cannot hold this

Three reasons. All structural.

Tacit knowledge is not accessible on demand. The expert does not know they know most of it until the situation shows up. You can put them in a room and ask "how do you do this work?" and they will describe the official process, because that is the only version they can consciously articulate at rest. The real version only surfaces in response to a real case. That is not laziness. It is how tacit knowledge works. It has to be extracted through structured conversation about specific situations, not through a generic writing prompt.

Documents describe steps, not reasoning. A document says "review the application, verify the sources, make a decision." It does not say "check field 4 first because field 2 is usually stale, then call the underwriter on the client's side if the ratio is above 0.6 because their internal escalation is faster than ours." The reasoning is what makes the decision correct. The document has room for the steps and no room for the reasoning.

Documents go stale in silence. Even the parts of operating knowledge that do get written down drift over time. Policies change. Systems get renamed. A vendor gets replaced. The wiki page reflects last year's world. The team knows which lines to ignore. A new hire, or an AI agent, does not.

Add these three together and you get the situation nearly every large enterprise is in. There is documentation. There is a knowledge base. There is a chat-over-docs assistant bolted to a vector database. And the real work still lives in one or two people, because none of those layers were built to hold operating knowledge in the first place. This is the same reason Glean, Notion AI, and Copilot miss the real work. They are built on top of the documented layer, not the operating one.

Why this is the reason enterprise AI keeps failing

MIT NANDA's recent report found that 95% of enterprise AI investments show no measurable business impact. There are many stories about why. Most of them miss the substrate problem.

The pattern we see across dozens of projects is consistent. A team stands up a RAG system, an internal chat assistant, or an agent builder on top of the documents. The demo looks good. It handles clean cases well because clean cases are what documents describe. Then it hits real work. A case that does not fit any documented category. An exception that requires judgment. A situation where the standard policy does not apply.

The system either gives a generic answer, retrieves something adjacent but not quite right, or hallucinates a plausible answer that is wrong. Not because the model is bad. Because the substrate underneath the model has no operating knowledge in it. This is the knowledge leg of enterprise AI that most stacks skip, and it is why 95% of enterprise AI pilots fail on the transition from demo to production.

We wrote about this specifically in the context of retrieval, see Expertise Mining vs RAG for the longer version, but the point generalizes. Every layer of the enterprise AI stack reads from a substrate. If the substrate is documents, the agent inherits what the documents can and cannot say. And what the documents cannot say is exactly the part that matters on real cases.

There is a second, quieter failure mode too. Operating knowledge is fragile at the human layer. In the U.S. private sector, median employee tenure is 3.5 years [BLS]. When an experienced operator leaves, the operating knowledge leaves with them. That is not a training problem. It is a substrate problem. See The Expert Dependency Problem for the full picture. And it is also why 80% of your processes being undocumented is not a housekeeping issue. It is an operating risk that gets bigger every year.

What machine-readable expertise looks like

If documents cannot hold operating knowledge, what can?

The short answer: a machine-readable expert profile. A structured artifact that captures the decision logic, the exception handling, the trusted sources, and the escalation reasons, validated against real cases, connected to the systems the work actually runs in, and kept current as the operation changes.

That is what expertise mining produces. It sits with an expert in a normal conversation and pulls out the real work. Not a transcript, not a nicer wiki page. It captures the decisions, the reasons, the exceptions, the sources they trust, the moments they stop and escalate, and turns all of it into a form an AI can use directly.

A short example. A large multi-brand insurance group had an insurance renewal workflow that took about six minutes per case, run by an eight-person risk team. The work looked simple on paper: pull the file, check the fields, make the call. In practice, the six minutes were almost entirely operating knowledge: which fields to trust, which exceptions applied, when to escalate, which internal source was more current than the primary system.

We mined that operating knowledge into a machine-readable expert profile and connected it to the systems the team already used. Renewal handling time dropped from six minutes to one. The risk team went from eight people to three. A human still approves anything that matters, that is the point of governed agent operations, but the operating knowledge is now explicit, transferable, and running next to the team instead of walking out the door with one person.

That is what a captured operating knowledge looks like in production. Not a document. Not a search box. A structured, validated substrate that the AI reads from directly and that a human stays in control of.

The question every operations leader should ask

Before spending another quarter on documentation, search, or an AI pilot, ask this: does the knowledge my operation runs on exist in written form?

If yes, keep investing in documentation. If no, and honestly, in most enterprises the answer is no, the missing layer is operating knowledge. Not more documents. Not a better wiki. Not a bigger vector database. Extraction of the real process from the people who hold it, in a form your systems and your AI can actually use.

That is the whole point of expertise mining. Different substrate, different output, different category. And it is the layer nearly every enterprise is missing.

Mine the expertise. Then operate differently.