Post by 
August 25, 2026 | 
Tacit knowledge is the judgment your best people carry in their heads and never write down. It is the reason an experienced engineer knows a particular deployment window is risky even when the checklist says green. It is the reason a senior analyst flags an alert that a junior analyst closes. When you build AI systems to reason about your operations, that unwritten judgment determines whether the system helps or misleads. This article is about how to get it out of people’s heads without destroying their productivity or producing a false sense of documentation coverage.
The methods that work are not the ones that feel intuitive. Asking your experts to write things down is the most natural instinct and the one most likely to fail. What works instead is elicitation: structured techniques that extract reasoning at the right moment, reconstruct what you can from the work trail that already exists, and use expert time only for confirmation rather than creation.
Why asking experts to write documentation fails
The blank page problem is real. When you ask a domain expert to document their knowledge, you are asking them to perform two cognitively difficult tasks at once: recall what they know, and translate it into a format that will make sense to someone who does not share their context. Experts are fast at their work precisely because their judgment is automatic. Asking them to make it explicit is like asking someone to explain how they ride a bicycle while riding one.
The output you get is usually a surface-level procedure. They write what they can easily articulate, which tends to be the steps, not the reasoning behind the steps. The conditions under which a step changes, the signals that mean something has gone wrong before it looks wrong, the cases where the standard procedure does not apply: those stay invisible. You end up with documentation that looks comprehensive and is genuinely dangerous to use as the basis for an AI system.
There is also a time cost that compounds. Every hour a senior engineer spends writing documentation is an hour not spent on delivery. In most technical organizations under growth or operational pressure, this is not an abstract concern. Teams often deprioritize the knowledge capture effort, rush through it, or delegate it to someone who lacks the expertise to identify what is missing.
The shift from documentation to elicitation
Elicitation flips the burden. Instead of asking the expert to produce, you ask them to react. A draft that is 70 percent correct gets reviewed and corrected far faster than a blank page gets filled. The expert’s cognitive load drops because they are evaluating rather than generating. The output quality rises because they are catching errors rather than trying to recall everything from scratch.
The key is where the draft comes from. You build it before the expert sees it, using every signal the work already produces: incident tickets, pull request comments, escalation histories, post-mortems, review threads, architectural decision records. These artifacts contain reasoning in context. The decision was made in the moment, which means the reasoning is anchored to something real rather than reconstructed from memory weeks later. Mining these artifacts is high-yield because the effort friction is low and the contextual fidelity is high.
Capture at the moment of decision
The highest-value capture point is immediately after a decision, while the reasoning is still fresh. A post-incident review held 48 hours after an outage is more valuable for knowledge capture than a documentation sprint held six months later. A quick structured question asked after a non-standard deployment decision captures more real reasoning than a quarterly documentation session.
The structured questions matter here. “Why did you do it that way?” is too open. Better questions are more constrained: What signal made you deviate from the standard approach? What would have had to be true for you to escalate instead? What would you tell someone handling this scenario next time that is not in the runbook? These questions target the gap between the documented procedure and the actual judgment being exercised.
Present a draft and ask for corrections
Once you have reconstructed a draft from the artifact trail, you bring it to the accountable person for a single structured review. The format matters: the draft should be concrete and specific enough to be wrong about something. A draft that says “engineer assessed risk as acceptable” is too vague to correct. A draft that says “deployment was approved despite the migration running in parallel because the rollback window was judged sufficient” is specific enough for the expert to say “no, the real reason was that the migration was read-only at that point.” That correction is the tacit knowledge you needed.
Keep the confirmation step short and bounded. Thirty minutes with the right person, focused on a prepared artifact, produces better results than a two-hour interview with no structure. The expert is doing one thing: marking what is wrong and adding what is missing. Everything else is already drafted.
Validation and decay signals
Captured knowledge needs an owner and an expiry signal, not just a storage location. The owner is the person who can say whether the captured reasoning still applies. The expiry signal is any change in the environment that could make the reasoning outdated: a technology change, an org chart change, a shift in scale, a new regulatory constraint. Without these two things, a knowledge base accumulates entries that were accurate on the day they were captured and have silently drifted since.
Decay signals do not need to be sophisticated. A simple attribute on each captured item that records what type of change would invalidate it is enough to build a lightweight review trigger. When a system dependency changes, you surface every knowledge item that flagged that dependency as its decay condition. When an expert leaves, you surface the items for which they were the sole validator. This is a governance mechanism, not a technology problem.
What goes wrong
Two failure modes are worth calling out specifically because they are common and because the consequences are asymmetric.
Shallow elicitation produces confident-but-wrong playbooks
A playbook that is missing steps is obviously incomplete. An AI system operating on it will run out of guidance and either halt or escalate. A playbook that contains the wrong reasoning is worse: it looks complete, it produces outputs confidently, and the errors are not visible until something breaks in production. This is the failure mode of shallow elicitation. You asked the questions but did not go deep enough to catch the conditions and exceptions that the expert holds implicitly.
The specific symptom to watch for is a playbook where every step is unconditional. Real expert judgment is conditional: “if X, then Y, but if Z is also true, then do W instead.” If your captured knowledge reads like a linear procedure with no branches, you have surface-level documentation dressed up as expert judgment. An AI system trained or prompted on that material will behave confidently in edge cases where a human expert would pause and reassess.
Mining communications raises trust friction
Using chat histories, email threads, and meeting transcripts as a source for knowledge reconstruction is operationally attractive. The content is already there, the effort to extract is low, and the reasoning is often more candid than anything written for a documentation system. The problem is that people modify their communication behavior when they know it is being analyzed for capture.
If engineers know their Slack messages are being mined to build AI training material, they write differently. The candid “I have a bad feeling about this, let us wait” becomes a more formal message that is easier to justify but less useful as a signal of expert intuition. The trust cost is real and it does not recover quickly. If you use communication channels as an artifact source, be transparent about it, explain what you are capturing and why, and give people a way to mark content as off the record for this purpose. The alternative is to quietly mine the data and discover six months later that your highest-signal sources have gone quiet.
Where this fits in the broader AI readiness picture
Tacit knowledge capture is one layer of a larger preparation effort. If you are working through what your organization needs before AI can reason reliably about your operations, the Organizational Context for AI: The Complete Guide covers the full stack, from structured data quality through to the governance mechanisms that keep context current over time. Tacit knowledge is the hardest layer to get right, but it does not exist in isolation. An AI system that has good explicit documentation but missing expert judgment will fail in edge cases. One that has captured judgment but no governance structure will gradually drift from reality. Both are required.
Making it operational without grinding delivery
The goal is a lightweight, continuous capture habit rather than a periodic documentation project. Periodic projects produce a burst of activity, a body of content that was current on the day it was written, and then nothing until the next project. Continuous capture means building elicitation moments into the work that already happens.
Post-incident reviews, architecture decision records, non-standard approval requests, and escalation handoffs are all natural capture points. Each one already involves an expert explaining their reasoning to someone else. The change is adding a structured extraction step and routing the output into a governed repository rather than letting it disappear into a ticket comment or a meeting summary.
The discipline is in keeping the overhead thin. A capture process that requires 15 minutes per incident will survive. One that requires 90 minutes will be skipped under pressure, which means it will be skipped exactly when the most interesting decisions are being made. Design for the high-pressure version of your team, not the calm one.
