Is It Really Tacit Knowledge?

The perspective of this article
This article does not attempt to settle the academic definition of tacit knowledge. It presents a practical view developed by GFLOPS as the provider of AskDona Batch Assessment, an AI-assisted solution for assessment, audit, review, and questionnaire workflows.
Our concern is not to win a terminological debate. It is to identify what kind of knowledge an organization is actually dealing with, so that it can choose the right method of documentation, standardization, transfer, automation, and human review.

“We need to capture the tacit knowledge of our experienced employees.”

The phrase appears in discussions about manufacturing skills, sales expertise, customer support, audits, reviews, and many other forms of knowledge work.

Only one person knows how it works. It is not written in the manual. It may disappear when that person leaves. The natural response is to interview the expert, document what they know, and make the resulting knowledge available to AI.

The concern is valid. The label, however, is often too broad.

When we look closely at what organizations call “tacit knowledge,” we find several fundamentally different problems grouped under the same term. Some knowledge is genuinely difficult to articulate. Some facts have simply never been recorded. Some rules have never been defined. Sometimes the information exists, but only one person knows where it is or how two documents relate to each other.

Treating all of these as tacit knowledge obscures both the cause of the problem and the appropriate remedy.

In the age of AI, the first task is not to convert every form of tacit knowledge into explicit knowledge.

The first task is to determine what kind of “unwritten knowledge” we are actually dealing with.

Tacit knowledge is not simply knowledge that has not been documented

Michael Polanyi’s The Tacit Dimension made the idea of tacit knowledge widely influential. People can recognize a face or ride a bicycle without being able to describe every perception and bodily adjustment involved. Polanyi’s concern was not merely missing documentation. It was the tacit dimension inherent in the act of knowing itself.[1]

Ikujiro Nonaka’s work, and later the knowledge-creation model developed with Hirotaka Takeuchi, brought the interaction between tacit and explicit knowledge into mainstream management thinking.[2][3]

The concept has also been contested. Haridimos Tsoukas argued that management scholarship often reduces tacit knowledge to knowledge that has not yet been articulated, as though it could simply be translated into explicit rules. In his reading of Polanyi, tacit knowing is not a detachable package waiting to be converted.[4]

Harry Collins provides another useful distinction. Rather than treating tacit knowledge as a single category, he separates relational, somatic, and collective tacit knowledge. His framework is especially helpful for distinguishing knowledge that could, in principle, be made explicit from knowledge rooted in the body or in participation in a social community.[5]

The academic debate is therefore already more nuanced than the way the term is often used in business.

What we have learned from providing Batch Assessment

AskDona Batch Assessment reviews organizational documents and evidence against a set of assessment items. The AI agent prepares a first-pass result, rationale, cited passages, source documents, and missing information. Human reviewers then verify the output, add context, correct it where necessary, and make the final decision.[8][9]

Designing such a workflow forces us to decompose judgments that were previously handled with “an experienced reviewer will know.”

• What is in scope?
• Which documents should be searched?
• What qualifies as sufficient evidence?
• How should a policy be distinguished from an operational record?
• How should multiple conditions be aggregated?
• When does missing information mean non-compliance, and when does it mean indeterminate?
• What may the AI assess, and what must remain a human judgment?

Once these questions are made explicit, much of what had been called tacit knowledge turns out to have a different character.

Six types of “unwritten knowledge” found in organizations

For practical purposes, we find it useful to separate at least six categories.

Type	Example	Appropriate response
Unrecorded facts	Current settings, affected assets, exceptions, execution dates, approval status	Record them in systems, inventories, configurations, or operational evidence
Unarticulated rules	Definitions, scope rules, evidence requirements, decision priorities	Define them in policies, evaluation specifications, and decision criteria
Unmapped relational knowledge	Which document applies to which object, official names versus local names, ownership, current versus obsolete versions	Create metadata, mappings, ownership records, and version controls
Unstandardized procedural knowledge	Where to search, in what order to review evidence, whom to ask	Standardize the search strategy and workflow
Experience-based judgment	Detecting weak evidence, evaluating exceptions or compensating controls	Accumulate cases and rationales, while retaining human review
Embodied or collective tacit knowledge	Sound, vibration, touch, force, timing, or practices learned through participation in a community	Transfer through apprenticeship, demonstration, sensors, simulation, and shared practice

This is not offered as a new academic taxonomy. It is an operational classification developed from the perspective of a Batch Assessment provider, intended to help organizations choose the right intervention.

The key point is that the first four categories can, in principle, be documented, defined, or structured to a significant degree.

Something is not inherently ineffable merely because only one employee currently knows it.

Many problems in assessment work are not tacit knowledge at all

Consider several examples from security and control assessments.

“This system uses a self-signed certificate.”

Even if only one system owner knows this, it is not necessarily tacit knowledge in the narrow sense.

It is an unrecorded system-specific fact. It should be captured in a configuration document, certificate inventory, or system record.

“A self-signed certificate does not qualify as a publicly trusted certificate.”

This is not an intuition that should remain inside an experienced assessor’s head.

It is an unarticulated definition or decision rule that should be part of the assessment specification.

“This local register is the enterprise-wide inventory referred to by the control.”

If the formal status and naming relationship of the register are unclear, the problem is unmapped relational knowledge.

“The current information will not be in the design document; you need to check the change ticket.”

This may appear as assessor expertise, but at least part of it can be externalized as a search map or review procedure.

“This compensating control provides risk reduction equivalent to the specified measure.”

This decision requires technical, operational, and risk context. It contains genuine experience-based judgment and should normally remain subject to human review.

This distinction changes the diagnosis of the problem.

The central issue is often not that the organization has too much tacit knowledge. It is that recordable facts and definable rules have been allowed to remain implicit, while no distinction has been made between them and the judgment that truly requires expertise.

Manufacturing contains genuine embodied tacit knowledge—but it contains other problems too

Manufacturing provides clear examples of knowledge that is genuinely difficult to transfer through text alone.

An experienced operator may detect a problem through a slight change in sound or vibration, judge material condition through touch, or adjust speed and force based on resistance felt during a process. These capabilities emerge through repeated interaction between the body, the material, the equipment, and the environment. They are not simply missing paragraphs in a manual. Leonard and Sensiper similarly emphasized the role of experience-based, incompletely articulated knowledge in organizational capability and innovation.[6]

Yet not everything described as “craft knowledge” in a factory is embodied tacit knowledge.

• Machine-specific adjustment values may never have been recorded.
• Actual tolerances may not have been reflected in the standard.
• Failure patterns and causes may not have been organized.
• Reasons for past changes may have been lost.
• Work instructions may be obsolete.

These may be problems of data management, standard management, change management, or knowledge organization rather than inherently inarticulable skill.

Paul Adler’s work is useful here. The relationship between tacit and codified knowledge is dynamic, not fixed. Some knowledge developed in practice can be moved into guidelines, models, standards, and rules. At the same time, experience is still needed to know when those rules apply and when they should be overridden.[7]

The existence of genuine tacit knowledge in manufacturing does not justify calling every undocumented shop-floor fact tacit.

Low-resolution use of the term leads to the wrong intervention

When different problems are collapsed into the single category of tacit knowledge, organizations often choose the wrong remedy.

Actual problem	Common but ineffective response	More appropriate response
Unrecorded fact	Conduct an expert interview and leave the result in meeting notes	Improve the system of record, inventory, or evidence capture
Unarticulated rule	Collect more examples without defining the rule	Establish definitions, scope, evidence requirements, and decision logic
Unmapped relationship	Write another manual	Create metadata, mappings, ownership, and version controls
Unstandardized procedure	Leave the process to individual ingenuity	Standardize search order, review steps, and escalation paths
Experience-based judgment	Force the judgment into a single deterministic rule	Preserve cases, rationales, and expert review
Embodied tacit knowledge	Try to transfer it through text alone	Use demonstration, repetition, video, sensors, or simulation

If every problem is treated as “tacit knowledge conversion,” facts that should become structured data remain trapped in interview notes, rules that should be formalized remain buried in casebooks, and bodily skills are reduced to manuals that cannot reproduce the experience required to learn them.

Why asking AI to “infer tacit knowledge” is dangerous

Generative AI has created an understandable expectation: perhaps the model can fill in what experienced employees know but have never written down.

AI can certainly support knowledge work.

• It can retrieve relevant passages from large document collections.
• It can map variant terminology.
• It can classify past decision rationales.
• It can identify candidate rules.
• It can surface contradictions and missing evidence.
• It can prepare a first-pass assessment for review.

But the fact that AI can assist does not mean it should invent missing facts.

Inferring an undocumented system setting from general product knowledge, creating an organizational decision rule from plausible industry practice, or treating surrounding context as proof of a system-specific condition is not the use of tacit knowledge. It is unsupported factual completion.

Assessment work therefore needs a clear separation between three layers.

1. Interpretive knowledge
   Definitions, organizational terminology, scope, and prior cases used to understand the question and the evidence.

2. Decision evidence
   System configurations, contracts, records, logs, test results, or other information that directly supports the current decision.

3. Decision rules
   The conditions that convert confirmed facts into results such as compliant, non-compliant, out of scope, or indeterminate.

Interpretive knowledge is necessary to read evidence correctly. It must not be treated as evidence that a particular control is implemented.

How this view shapes the design of Batch Assessment

This distinction is reflected in the design approach of Batch Assessment.

Administrators can define the RAG knowledge base, fixed reference documents, and metadata-based evidence scope used for an assessment. They can also define not only the names of evaluation options, but the concrete conditions for selecting each option, the evidence required, and the handling of insufficient information.[8]

Prompt design is organized around several principles:

• Decompose requirements before deciding.
• Distinguish policy evidence from implementation and operational evidence.
• Confirm the scope and effective date of evidence.
• Apply a fixed decision sequence.
• Explicitly prohibit unsupported inferences, such as turning missing evidence into non-compliance or general knowledge into system-specific facts.

The AI agent retrieves documents and evidence, then organizes confirmed facts, rationale, quotations, sources, and missing information. Human reviewers retain responsibility for ambiguous evidence, exceptions, compensating controls, organization-specific interpretation, and risk acceptance.[8][9]

The objective is not to reproduce an experienced employee’s mind inside the model.

The objective is to separate knowledge that should be structured for AI from judgment that should remain accountable to people.

AI errors reveal gaps in the organization’s knowledge structure

When an AI system produces a wrong result, it is not enough to say that the model lacks accuracy.

The error may reveal that:

• a term was never defined;
• a system-specific fact was never recorded;
• the relationship between documents was never mapped;
• the threshold for sufficient evidence was never specified;
• the aggregation rule for multiple conditions was absent; or
• past exception decisions were never preserved.

Seen this way, AI is less a machine for automatically extracting tacit knowledge than a mechanism for exposing gaps in the organization’s knowledge architecture.

Humans often bridge those gaps through experience, making deficiencies in the process difficult to see. AI either bridges them differently or stops at them, making the missing assumptions visible.

Six questions to ask before calling something tacit knowledge

When information is known by only one person, ask the following questions before labeling it tacit.

1. Is it a fact about a specific object or point in time?
   If so, it should be recorded as data, configuration, inventory, or evidence.

2. Can it be stated as a stable condition?
   If so, it belongs in a definition, policy, operating rule, or evaluation specification.

3. Is it information about how things relate?
   If so, it may require metadata, mappings, document ownership, or responsibility boundaries.

4. Is it knowledge of where to search or whom to ask?
   If so, it can often be standardized as a search strategy or workflow.

5. Can the judgment be explained through prior cases and rationales?
   If so, it can be partly externalized as case knowledge and used in human-AI review.

6. Does it require bodily experience or participation in a social practice to acquire?
   If so, it is more likely to be tacit in the stronger sense, and documents alone will not transfer it.

Move from “converting tacit knowledge” to identifying the attributes of knowledge

Tacit knowledge is real.

Experienced diagnosis, sensitivity to exceptions, judgment about when rules should be overridden, embodied skill, and practices learned through participation are all important forms of organizational knowledge.

But not every problem described as tacit knowledge belongs to this category.

From our experience providing Batch Assessment, genuinely person-specific tacit knowledge represents a more limited portion of assessment work than the language often suggests.

Much of the problem is not knowledge that cannot be written. It is knowledge that has not yet been written.

It is not unknowable knowledge. It is an unrecorded fact.

It is not an inherently unformalizable judgment. It is a rule the organization has never defined.

The challenge in assessment work is not simply the volume of tacit knowledge. It is the failure to distinguish information that can be recorded, defined, and structured from judgment that genuinely needs to remain with people.

The goal in the age of AI is therefore not to force all tacit knowledge into explicit form.

Organizations need to decide what should become data, what should become rules, what should become relational metadata, what should become case knowledge, what should remain a human judgment, and what must be learned through embodied practice.

Once the convenient label of tacit knowledge is unpacked, organizations can choose far more appropriate approaches to knowledge transfer, process standardization, and AI adoption.

References

1. Polanyi, M. (1966). The Tacit Dimension. Doubleday. Reprinted by the University of Chicago Press. Publisher page
2. Nonaka, I. (1994). “A Dynamic Theory of Organizational Knowledge Creation.” Organization Science, 5(1), 14–37. https://doi.org/10.1287/orsc.5.1.14
3. Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company: How Japanese Companies Create the Dynamics of Innovation. Oxford University Press. Publisher page
4. Tsoukas, H. (2003). “Do We Really Understand Tacit Knowledge?” In M. Easterby-Smith & M. A. Lyles (Eds.), The Blackwell Handbook of Organizational Learning and Knowledge Management, 411–427. Blackwell. Author manuscript
5. Collins, H. (2010). Tacit and Explicit Knowledge. University of Chicago Press. Publisher page
6. Leonard, D., & Sensiper, S. (1998). “The Role of Tacit Knowledge in Group Innovation.” California Management Review, 40(3), 112–132. Harvard Business School record
7. Adler, P. S. (1995). “The Dynamic Relationship Between Tacit and Codified Knowledge: Comment on Nonaka.” In J. Allouche & G. Pogorel (Eds.), Technology Management and Corporate Strategies: A Tricontinental Perspective, 110–124. North-Holland. Author publication list and manuscript
8. GFLOPS Co., Ltd. (2026). How to Use Batch Assessment. Product guide.
9. GFLOPS Co., Ltd. (2026). AskDona Batch Assessment: Solution Overview. Product materials.