IATF16949 Practical Application (27) | Organizational Knowledge Retention: 12-Field Knowledge Asset Register, Review Failure Rules, and 7.1.6 Five-Question Evidence Collection

During the external audit at clause 7.1.6, the auditor asked the technical management department to "bring out the organizational knowledge accumulated over the past three years for review." The shared drive was opened, revealing three layers of folders and over 800 files, which looked quite substantial. The auditor randomly opened three files: one was the 2019 version of a work standard, which had already been revised three times; another was a compressed file that couldn't be opened; the third was a "project summary" that contained only conclusions and no data. The auditor then asked, "Has the experience from last year's batch rework on that production line been entered into the knowledge base?" The technical department responded, "It was discussed in the project group, and everyone remembers the conclusion."

A nonconformity was immediately issued: organizational knowledge had not been properly determined and maintained, and there was no mechanism for acquisition and updating.

The crux of the issue is not that "the company hasn't written anything," but that knowledge has never been managed as an asset. Assets have registers, ownership, expiration dates, disposal rules, and verifiable records. However, the company's knowledge management remains at the level of "files stored in a shared drive" — they don't know what they have in total, which items are outdated, or which items are known by only one person. This article does not discuss how to extract the skills of experienced workers (that's a matter of extraction methods), but focuses on one thing: how to manage knowledge after it is entered into the knowledge base, similar to how equipment and measuring tools are managed, and how to present evidence during audits.

1. Distinguishing Between Three Types: Documents, Records, and Knowledge

Clause 7.1.6 is often cited for nonconformities due to the confusion between these three concepts. The management rules for each are entirely different, and mixing them can lead to the strange phenomenon where "documents are well-controlled, but no knowledge can be found."

To determine if something is "knowledge," use the three-question filter:

1. Can someone in another position use it directly without an explanation? If yes, it is knowledge; if it requires the author's explanation, it is personal experience.
2. Does it answer "why" and "to what extent"? "Inspect the first piece carefully" is not knowledge; "Pre-tightening torque 1.8～2.2 N·m and no sticking sensation, if sticking, reapply lubricant and retest" is knowledge.
3. Under what conditions will it become obsolete? Knowledge that cannot specify its obsolescence conditions is usually just a recount of a single successful instance.

Only items that pass all three questions are worth entering into the register. This step alone can reduce the number of true knowledge items from 80 to about 50 in a set of 80 files — this is not a bad thing, but a clear understanding of what the company truly possesses.

2. What Types of Knowledge Does 7.1.6 Require?

The clause clearly defines internal knowledge points: intellectual property, knowledge gained from lessons learned (both failures and successes), knowledge from improvement outcomes, and knowledge from changes. External knowledge includes standards, academic achievements, industry conferences, and knowledge provided by customers and suppliers. When it comes to the register, each type must be linked to a carrier and the minimum evidence required; otherwise, it will be impossible to determine during inventory whether "this type of knowledge exists."

During inventory, the last category is often overlooked. External knowledge is not just "downloading standards," but "whether external requirements have been translated into the company's document clauses." When auditors ask about 7.1.6, if the company responds, "We have all the standards," the next question is usually, "Which 2026 version special requirement from the customer is implemented in which control plan?"

3. Knowledge Asset Register: 12 Fields

The register is the backbone of the entire mechanism. Too many fields make it difficult to fill out, while too few make it impossible to judge. The 12 fields are the minimum set that can simultaneously meet the requirements of "searchable, judgable, and verifiable."

Two filling examples (anonymized):

KB-Assembly-013 | Worm gear pre-tightening feel criterion (noise-related failure) | Technical criterion | One-page card + video | 7.1.6, 8.5.1 | Assembly process / Elevator assembly | Assembly Process Engineer | 2 people | 2026-03-01 / 12 months / 2027-03-01 | Current | 7 times | Internal

KB-Injection-021 | PC+ABS material batch switching mold temperature compensation range | Process parameter | Parameter table | 7.1.6, 8.5.1 | Injection process / Exterior parts | Injection Process Engineer | 1 person | 2026-05-10 / 12 months / 2027-05-10 | Pending review | 0 times | Restricted

The 8th and 11th fields are the true value of this register. The former turns "only Wang knows" into a statistically trackable number, and the latter turns "the knowledge base has a lot of content" into "how many items have been used in the past six months." A register with only the first ten fields is a pretty list; filling in these two fields makes it a management tool that drives actions.

4. Criteria for Four States

The status field is not just a label but a judgment result, and it must clearly state the triggering conditions and disposal actions. Otherwise, it will always remain "current."

Five signals that trigger a review; any one of these requires an early review, without waiting for the cycle:

1. The standard, regulation, or customer special requirement that cites this knowledge has been revised.
2. A nonconformity with the same root cause recurs ≥2 times within 12 months (indicating insufficient or incorrect knowledge).
3. Associated drawings, materials, equipment, or process parameters have changed.
4. The unique holder of this knowledge has changed positions (transfer, resignation, long-term external assignment).
5. The knowledge is cited but still fails (ineffective countermeasures, incorrect criteria).

The 2nd and 5th signals are the most easily overlooked and the most valuable: the true enemy of the knowledge base is not "lack of content," but "incorrect content being used as a basis." A criterion that fails three times despite being cited is more dangerous than not having the criterion at all.

Review cycle parameter table (adjustable by industry, but must be written into procedure documents):

5. Retirement and Consolidation: Knowledge Also Needs to Be Removed

A knowledge base that only adds and never removes will inevitably become a pile of outdated materials that no one dares to trust after three years. The retirement rules must specify three actions.

Action One: Zero citations trigger evaluation, not automatic retirement. Items with zero citations for 12 consecutive months are reviewed item by item at each quarterly knowledge review meeting. The conclusions are only three: maintain (categorized as low-frequency high-value, add "low-frequency retention" mark and extend review cycle), consolidate (multiple items on the same topic), or withdraw (replaced or mechanism disproven). It is never acceptable to batch delete items based on zero citations — knowledge such as regulatory requirements and rare failures is inherently low-frequency.

Action Two: Consolidate similar topics, retain old codes. When a topic accumulates three or more items (e.g., "noise in a certain process" documented by different projects), consolidate them into a main entry, and mark the others as "consolidated into KB-XXX." During consolidation, combine the failure conditions of each item, which often reveals contradictions among the criteria.

Action Three: Withdraw but do not delete. Retain the code, name, withdrawal date, replacement code, and reason for withdrawal. There are two reasons: one is traceability (which version of the criterion was used for a customer complaint three years ago must be verifiable), and the other is to prevent "reinventing the wheel" — the same mistake documented by two project teams is a common waste in knowledge management.

6. Departure and Position Change: Turn Knowledge Recovery into a Checklist

The loss of knowledge in key positions can be identified by the "backup rate," but it cannot fill the content gap. A recovery checklist, following a four-step timeline, is needed to address this.

Three criteria for release, all are essential:

1. The receiver can provide criterion-level answers for three boundary cases within 10 minutes (stating the basis for judgment and the action to take, not "ask Wang").
2. The key parameter table and criterion card have a second person's signature (not just confirming "received," but verifying "independently tested").
3. The number of unique holders for the knowledge item in the register is ≥2.

The 3rd criterion is often bypassed: the company conducts a round of handovers, but the register is not updated. Six months later, the number is still 1 — indicating that the handover only occurred between people, not in the asset register.

7. 7.1.6 Audit Evidence Collection: Five Questions and Evidence Packages

When auditors check 7.1.6, the path is almost always the same five questions. The company should not rely on on-the-spot explanations but should have corresponding, immediately retrievable evidence for each question.

Among the five questions, the 4th and 5th are the most critical and the easiest to address within two days: the 4th question only requires a bidirectional alignment of the current CSR matrix and document list; the 5th question only requires adding a "cited knowledge code" column to the FMEA and design review forms. These two changes are extremely low-cost but have a far greater impact on the audit conclusion than writing another "Knowledge Management System" policy.

Conversely, there are three types of failures that cannot be rectified: the work standard found on-site is a withdrawn version (failure of the 10th field); the criteria in the knowledge base contradict the current control plan (failure of the 11th field); customer confidential data is shared indiscriminately (failure of the 12th field). Once these are caught, the issue shifts from "incomplete mechanism" to "loss of control over documented information."

8. 30/60/90-Day Implementation Plan

To determine if this has been successfully implemented, don't just look at the number of items in the register; focus on three metrics: the percentage of items with a unique holder count of 1 (target to decrease quarterly), the percentage of items cited in the last 12 months (target to increase quarterly), and the number of items overdue for review (target to approach zero). If these three metrics are improving, it indicates that knowledge is truly being managed as an asset; if only the first metric is increasing, it suggests that a more organized file cabinet has been created.

9. Key Points and Common Mistakes

Key Points:

1. First define what counts as knowledge, then discuss entry. Without the three-question filter, the register will become a duplicate of the document list within three months.
2. Fill in the Owner with the position, not the name. This is the critical point for the mechanism to survive personnel changes.
3. Each knowledge item must have a next review date. Assets without an expiration date are effectively unmanaged.
4. Citations must leave a trace, and the traceability cost must be low. Adding a column to existing forms is ten times more effective than building a new system.
5. Withdrawn items are not deleted. Retaining for traceability and preventing reinvention of the wheel are both compelling reasons.
6. External knowledge must be converted. The value of standards and CSR lies not in archiving but in their implementation in specific document clauses.

Common Mistakes:

1. Only a shared drive, no register. Inability to find or explain items on-site is essentially "undetermined organizational knowledge."
2. Too many fields in the register. Forms with 20+ fields are not maintained, leading to large-scale blank fields after six months, which is worse than having too few fields.
3. Case library only collects success cases. 7.1.6 explicitly mentions "knowledge gained from lessons learned," and the absence of failure cases is the most typical point of failure.
4. Status always shows "current." Zero "pending review" items in the entire table indicate that the review mechanism is only on paper.
5. Knowledge is decoupled from management documents. FMEA and control plans not citing knowledge codes turn the knowledge base into an isolated island.
6. Skill matrix is used as a knowledge register. The skill matrix manages "who knows," while the knowledge register manages "whether the knowledge exists, is correct, and can still be used" — they complement each other but are not interchangeable.
7. Zero citations lead to deletion. A batch deletion can remove truly hard-to-obtain knowledge such as regulatory requirements and rare failures.
8. Confidentiality clauses are not specified. Indiscriminate sharing of customer data can result in a breach of contract.

The challenge in organizational knowledge management is not in "writing" but in "managing": writing is a matter of experience, while managing relies on registers, dates, and citation traces. By implementing these three elements, 7.1.6 will no longer be a question of on-the-spot explanation but a verifiable asset list that can be opened and shown to others at any time.

Knowledge should be managed like equipment, with a register and defined cycles

Knowledge code: 15.1.1

Version: v20261009

Author: QTank QTank is dedicated to providing systematic professional knowledge, methodologies, and practical tools for quality management practitioners, helping companies continuously improve their quality capabilities.