Tacit Knowledge Is Not Just an Undocumented Procedure
Polanyi's account of tacit knowing draws a necessary line between knowledge that has not been recorded and skill that cannot be fully turned into statements.
An experienced mechanic says a machine does not sound right. They can point to the machine, tell you when the sound began, and perhaps name a failure they suspect. Ask for a complete description of the sound and every distinction behind the judgment, and the account may become less certain. They have heard thousands of ordinary cycles and a few consequential deviations. Much of the comparison happens before a neat sentence arrives.
Michael Polanyi argued that knowing includes such capacities and that we can know more than we can tell. His point was not merely that people are poor at writing manuals. He challenged the expectation that every part of human knowing can ultimately be made fully explicit. (Polanyi, The Tacit Dimension)
This matters to knowledge engineering because the field’s early vocabulary encouraged builders to imagine an expert’s knowledge as a collection of statements awaiting capture. The mechanic’s judgment is not an empty slot in a database. It is a practiced capacity, exercised with perception, history, and material context.
Two different gaps
Suppose Maria knows a procedure and can explain every step, but nobody has written it down. The organization has an undocumented procedure. A careful interview, observation, and review of real cases may produce a useful record. The work may be tedious or politically difficult, but the central problem is not that the knowledge cannot be articulated.
Now suppose Maria recognizes an incipient fault from sound and vibration but cannot specify all the cues that lead to her judgment. A transcript of “it doesn’t sound right” preserves her warning without preserving her ability to make it. The organization may need apprenticeships, comparative recordings, repeated cases, and a way for less experienced workers to ask for her attention. A system might learn to flag some patterns from sensors, but a model trained on labeled examples would be another representation with its own errors, not a complete copy of Maria.
Calling both gaps tacit knowledge leads to poor decisions. In the first case, the organization may need documentation and a current owner. In the second, it may need conditions for practice and feedback as well as any records it can make. The difference changes what a knowledge engineer should attempt to build.
A representation can still help
Polanyi’s argument is sometimes used to imply that formal systems are futile because important knowledge escapes articulation. That conclusion does not follow. A system can preserve maintenance intervals, identify the right machine version, record unusual sounds, connect those observations to later inspections, and help people compare cases. It can make some of the mechanic’s work more visible without claiming to have captured all of it.
The engineering question becomes one of boundary and purpose. Which distinctions can be represented reliably? Which observations should remain observations until checked? Where is human practice needed to interpret a signal? How will the system show what it cannot establish? A list of everything Maria said is less useful than a representation that supports these questions at the point of work.
Knowledge management has to attend to the relationships, training, routines, and conditions through which such skill survives. Knowledge engineering can make some of those conditions operational in a system. Neither discipline is well served by pretending that every unrecorded capacity is a document waiting to be written.
By the late twentieth century, knowledge engineers were beginning to say this more directly. They were not transferring intact expertise from minds into machines. They were constructing models of a field and task, then testing those models against the work they were supposed to support.
