Eighteen months after the plant captured Dave the inspector's twenty years of know-how into a searchable knowledge base, a new hire on Line 2 typed a question into it: "Press 3 keeps throwing a low-pressure fault on startup, what do I do?" The knowledge base answered confidently, in Dave's own captured words: "Press 3 always reads low on a cold start, it is the slow accumulator, just bypass the startup interlock and let it run five minutes to warm up, it clears itself." The new hire bypassed the interlock. What he did not know, because the knowledge base did not know, was that fourteen months earlier the maintenance team had replaced that exact accumulator and rebuilt the pressure circuit. The fault was no longer a harmless cold-start quirk. It was a real low-pressure condition, and bypassing the interlock that morning sprayed hydraulic fluid across the operator station. Nobody was hurt, barely. The knowledge base was not wrong when Dave said it. It became wrong fourteen months later, and nobody told it. That is the central danger of every plant knowledge base built on captured expertise: the plant keeps changing, and a knowledge base that does not change with it slowly turns into a museum of how the plant used to run. This lesson is about the versioning and validation that keeps it honest.

Why a Knowledge Base Rots

A machine-vision model or a predictive-maintenance model has a built-in honesty mechanism: reality keeps testing it. The camera grades a part, the part either was or was not defective, and you find out. The model flags a bearing, the bearing either fails or it does not. The feedback loop is short and brutal, which is why the earlier lessons on drift and alert fatigue exist at all. A knowledge base has no such loop. It answers a question, the answer feels authoritative, and unless someone happens to know it is wrong, nobody ever closes the loop. A stale model degrades loudly through false rejects and missed failures. A stale knowledge base degrades silently, and the first sign is often an incident.

The reason a knowledge base rots is that it is a snapshot of a moving target. The plant the knowledge base described on the day of capture is not the plant running today. Consider everything that changes underneath a captured procedure over eighteen months. A pump gets rebuilt. A supplier changes a resin grade and the cure time shifts. An engineering change order (ECO, the formal document that authorizes a change to a part, process, or specification) revises a torque spec from 45 to 52 newton-meters. A guard gets added after a near miss, changing the access sequence. A control program gets patched and a startup interlock now behaves differently. Each of those changes quietly invalidates a piece of the knowledge base, and none of them automatically reaches in and updates it.

A knowledge base does not have to be wrong on the day you build it to hurt you. It only has to stay still while the plant moves.

This is a different failure mode from the hallucination problem covered earlier in the program, where the AI invents a torque spec it never had. Here the spec was real and correct at capture. The knowledge base is faithfully reporting a true fact that has since become false. That makes it more dangerous, not less, because the usual defense, "verify it against the drawing," fails: the captured answer matched the drawing perfectly on the day it was written. The drawing changed. The knowledge base did not. An honest knowledge base is not one that was accurate once. It is one that has a mechanism to notice when it has gone out of date and a process to correct itself.

Version Everything Like a Quality Document

Manufacturing already knows how to keep documents honest, because the quality system demands it. Under IATF 16949 (the automotive quality management standard) and AS9100 (its aerospace equivalent), no controlled document floats around without a revision number, an effective date, an owner, and a change history. You would never let an operator work from an uncontrolled, undated work instruction, because you cannot defend it in an audit and you cannot trust it on the floor. A knowledge base entry deserves exactly the same discipline, and the failure of most plants is that they treat the knowledge base as a casual wiki instead of a controlled document set.

Every entry in an honest knowledge base carries metadata that a quality engineer would recognize on sight.

A version and an effective date. The Press 3 entry should read "v1, captured 2024-09, from D. Reyes (retired inspector)." When the accumulator was replaced, that should have triggered "v2, effective 2025-11, supersedes v1." A reader, human or AI, should always be able to see which version they are looking at and when it took effect.

An owner. A named person or role accountable for whether the entry is still true. Tribal knowledge with no owner is exactly how the Press 3 entry survived fourteen months past its expiration. When the accumulator job closed, the owner of that entry should have been notified to review it.

A source and a confidence level. Where did this come from, and how sure are we? An entry sourced from a controlled work instruction and a current drawing is high-confidence. An entry sourced from one retiring expert's recollection, never validated against the equipment, is provisional, and it should be labeled that way so the new hire weighs it accordingly. The previous lesson on the expert-to-knowledge-base workflow is where these confidence levels get assigned at capture; this lesson is about maintaining them over time.

A review date. Every entry gets a next-review date, the way a calibration sticker carries a due date. A knowledge base entry with no review date is like a gauge with no calibration sticker: you have no idea whether to trust it, and in an audit that uncertainty is itself a finding.

Versioning is not bureaucracy for its own sake. It is the difference between a knowledge base you can stand behind in front of a customer auditor and a folder of undated notes that becomes a liability the moment something goes wrong. When the customer asks "how do you know your operators are working to the current process," the answer is the version control, the effective dates, and the review history. There is no other defensible answer.

What versioning would have cost, and saved, on Press 3

Put a number on it. The hydraulic spray incident triggered a containment, a safety stand-down across all three shifts, an investigation, and a corrective action, conservatively a full day of lost production on Line 2 at roughly $9,000 an hour, call it $72,000, plus the investigation labor and the unmeasurable cost of an operator who now distrusts the tool. The versioning discipline that would have prevented it costs almost nothing: a field on each entry and a trigger that, when the accumulator work order closed, flagged the Press 3 entry for its owner to review. A two-minute review against the closed work order would have superseded the entry. Two minutes of process, skipped, became a $72,000 incident and a near injury. That ratio is why versioning is not optional.

Tie the Knowledge Base to the Systems That Change

Asking a busy crew to remember to update the knowledge base every time the plant changes is a plan that fails, because the people making the change are not the people who own the knowledge entry, and they have no reason to think of it. Press 3's accumulator was replaced by a maintenance tech closing a work order, who had never heard of Dave's captured note and had no way to connect his repair to it. The honest knowledge base does not rely on memory. It hooks into the systems that already record change, so that a change in the real plant automatically raises a flag against the knowledge that describes it.

Three integration points carry almost all the value, and all three already exist in a typical plant.

The CMMS and the work-order stream. The computerized maintenance management system (CMMS, the software that holds work orders and maintenance history) is the record of every physical change to a machine. When a work order closes that replaces a component, that event should flag every knowledge-base entry tagged to that asset for review. The accumulator work order closing should have lit up the Press 3 entry like a check-engine light. This is the highest-value hook, because physical repairs are exactly the changes that silently invalidate captured know-how.

The engineering-change system. Every ECO that revises a spec, a tolerance, a material, or a procedure should flag the knowledge entries that reference the changed item. When the torque spec moves from 45 to 52 newton-meters, every work instruction, training note, and captured tip that mentions 45 should surface for review, because each is now teaching a stale number. The hallucinated-spec defense does not catch this; only the change linkage does.

The quality system and the corrective-action stream. When an 8D (the eight-discipline structured problem-solving method) or a corrective action concludes that a process must change, the new way of doing things has to flow into the knowledge base, and the old way has to be retired. A corrective action that fixes the floor but leaves the knowledge base teaching the old, defective method has only half-solved the problem. The next shift will read the old entry and reintroduce the defect.

The pattern across all three is the same: the knowledge base should be a subscriber to the plant's change events, not a separate island that someone remembers to update. You do not need a perfect digital twin to do this. You need the work-order close event, the ECO release, and the corrective-action closure to each carry a tag that maps to knowledge entries, and a queue that puts the flagged entries in front of their owners. That is brownfield-achievable with the systems most plants already run; it is integration, not a moonshot.

Validate Before You Serve, and Keep Validating

Versioning tells you when an entry might be stale. Validation tells you whether it is actually true. These are different jobs. An entry can be freshly versioned and still wrong, because the person who wrote it remembered it wrong, or because the AI summarized the capture inaccurately, or because the source itself was a plant myth. Keeping the knowledge base honest means validating entries both before they go live and on a recurring cadence after, and treating the knowledge base as a living quality document under continuous improvement, not a one-time data dump.

Validation happens at three moments, and skipping any of them lets a falsehood into the system.

At capture, validate against the authoritative source. Before a captured tip becomes a served entry, it gets checked against the controlled document that should govern it: the drawing, the work instruction, the equipment manual, the historian trace. If Dave says "torque it to 45" and the drawing says 52, the drawing wins and the discrepancy gets investigated, because either Dave was working to a superseded spec or the drawing is wrong, and you need to know which before you teach anyone anything. This is the same verify-against-the-source discipline the whole program rests on.

At a recurring review, revalidate the high-stakes entries. Not every entry needs the same cadence. An entry that, if wrong, could cause a safety incident or a defect escape gets reviewed often, perhaps quarterly. A low-stakes entry about where the spare gaskets are stored can be reviewed annually or on event only. Prioritize the review effort by the cost of the entry being wrong, exactly the asymmetry logic from the alert-fatigue lesson: spend your scarce review attention where a stale answer hurts most. The Press 3 startup-interlock entry was a safety-critical, high-stakes entry that any sane review prioritization would have flagged for frequent revalidation.

At point of use, let the crew flag what does not match. The operators and techs using the knowledge base are your most powerful validation sensor, because they are the ones who notice when the captured answer does not match the machine in front of them. Every entry needs a one-click "this does not match what I am seeing" path that routes straight to the entry owner. The new hire on Press 3 sensed something was off, the cold-start explanation did not quite fit the fault he was seeing, but the system gave him no way to flag a doubt and no reason to distrust Dave's confident words, so he complied. A flag-it path turns every user into a validator and would have surfaced the stale entry before the bypass.

Closing the loop with usage data

An honest knowledge base also watches itself the way the alert-fatigue lesson watched the alert stream. A few signals tell you which entries are decaying. An entry that gets queried often but is rarely marked helpful is probably stale or unclear. An entry that triggers a flag-it report is a priority review. An entry that has not been viewed in a year and has no review date is a candidate for archiving, because dead entries are not harmless: they pad the base, dilute search results, and occasionally surface to someone at exactly the wrong moment, which is precisely what Press 3 did. Track query volume, helpfulness, flag reports, and age, and review them in the same cadence you review your quality documents. A knowledge base nobody curates is a knowledge base nobody should trust.

Retire the Stale Entry, Do Not Just Bury It

When an entry is found to be out of date, the instinct is to write a new one and move on. That is not enough, and the Press 3 incident shows why. If the v2 truth (the accumulator was replaced, the fault is now real) gets added but the v1 entry (the cold-start quirk, bypass the interlock) is left sitting in the base, the search can still surface the dangerous old answer. Adding the truth does not remove the falsehood. Keeping the knowledge base honest requires actively retiring superseded entries, not just appending corrections.

Retirement has to be deliberate and traceable, the same way a quality system controls obsolete documents so nobody works from a withdrawn revision.

Supersede, do not silently delete. Mark v1 as superseded by v2, with the date and the reason. You keep the history, because the history is part of the audit trail and part of how you learn, but the superseded entry no longer serves to a user asking the question. When someone searches Press 3 startup fault, they get v2 and only v2, with a note that a prior version existed and why it changed.

Carry the reason for the change. The retirement note should say why, in plain terms: "Superseded after accumulator replacement under WO-4471, 2025-11. The cold-start low-pressure behavior described in v1 no longer applies. A low-pressure fault on Press 3 is now a real fault. Do not bypass the startup interlock." That note teaches the next person not just the new truth but the fact that the situation changed, which is exactly the context the new hire lacked.

Propagate the retirement to everything that referenced it. If the stale tip was embedded in a training module, an onboarding checklist, or another entry, retiring the source has to ripple to the references, or the falsehood survives in a copy. This is why the captured knowledge should be linked, not copy-pasted, into the places that use it, so a single retirement reaches every use.

Notify the people who relied on it. If a crew was recently trained on the old method, retiring the entry quietly is not enough; the people carrying the stale knowledge in their heads need to be told it changed. The knowledge base is one copy of the knowledge; the crew's memory is another, and an honest update reaches both.

Retirement done this way turns the knowledge base from an accumulating pile into a curated, trustworthy resource. The test of an honest knowledge base is not how much it contains. It is whether, when a new hire asks it a question at 6 a.m. with no senior tech on the floor, the answer it gives reflects the plant as it is today, not the plant as it was the day someone wrote the entry down.

Governance, Roles, and the Audit Trail

None of this maintains itself. A knowledge base that stays honest does so because specific people are accountable for specific parts of it, on a specific cadence, with the whole thing logged. This is the same governance discipline the program applies to every AI-touched decision, because the customer audits you, not the vendor, and "the knowledge base said so" is no more a defense than "the model said no." The plant and the human who signs the record own the accuracy of what the crew is taught.

A workable governance model does not require a large team. It requires clear ownership and a rhythm.

Entry owners are the named people or roles accountable for whether their entries are still true. They receive the change flags from the CMMS, ECO, and corrective-action hooks, and they action the reviews. An entry without an owner is an orphan, and orphans are how rot spreads.

A knowledge-base steward owns the system as a whole: the review cadence, the usage metrics, the archiving of dead entries, and the integration health. This is often a quality engineer or a continuous-improvement lead, because the discipline is the same one they already apply to controlled documents. On a thin crew, where 85% of manufacturers say staffing shortages are hurting quality, this is a part-time role layered onto an existing job, not a new headcount, but it must be someone's named responsibility, not everyone's vague hope.

The review rhythm mirrors the quality calendar: high-stakes entries on a frequent cycle, the rest on event or annually, the usage metrics in the monthly meeting alongside the other AI-system metrics. The cadence is what catches the Press 3 entry before the plant catches it the hard way.

The audit trail is the byproduct that makes the whole thing defensible. Every version, every effective date, every review, every retirement, every flag-it report and its resolution, all logged. When a customer auditor asks how you ensure your operators work to the current process even with an AI knowledge base in the loop, you show them the version history and the review log. That trail is the difference between an AI knowledge base that strengthens your quality system and one that quietly undermines it. An honest knowledge base is, in the end, a governed one: owned, versioned, validated, tied to the plant's real changes, and able to prove all of it.

Key Takeaways

• A knowledge base does not have to be wrong at capture to hurt you; it only has to stay still while the plant moves. The Press 3 entry was true when Dave said it and became a safety hazard fourteen months later when the accumulator was replaced and nobody updated it. Stale knowledge degrades silently, and the first sign is often an incident.
• This is a different failure mode from hallucination. The captured fact was real and matched the drawing at capture, so "verify against the drawing" does not catch it; only a mechanism that notices the plant changed will. An honest knowledge base is not one that was accurate once, but one that can detect and correct its own staleness.
• Version every entry like a controlled quality document: a version and effective date, a named owner, a source and confidence level, and a next-review date. The discipline that prevents an incident costs a field and a trigger; on Press 3 that two-minute review skipped became roughly a $72,000 day plus a near injury.
• Make the knowledge base a subscriber to the plant's change events, not an island someone remembers to update. Hook it to the CMMS work-order close, the engineering-change (ECO) release, and the corrective-action (8D) closure, so a real change automatically flags the entries that describe it for their owners.
• Validate at three moments: against the authoritative source at capture, on a recurring cadence prioritized by the cost of being wrong (safety-critical entries reviewed often), and at point of use through a one-click flag-it path that turns every operator into a validator. The new hire sensed the Press 3 answer was off but had no way to flag it.
• Retire stale entries deliberately, do not just append a correction. Supersede rather than silently delete, carry the plain-language reason for the change, propagate the retirement to every place that referenced the entry, and notify the people trained on the old method. Adding the truth does not remove the falsehood from search.
• Honesty is a governance outcome: named entry owners who action change flags, a knowledge-base steward (often a quality or CI lead, a part-time role on a thin crew) who owns cadence and metrics, and an audit trail of versions, reviews, and retirements. The customer audits you, not the vendor; "the knowledge base said so" is not a defense.
• The test of an honest knowledge base is not how much it contains but whether the answer it gives a new hire at 6 a.m. reflects the plant as it is today. Curate it like a quality document, watch its usage metrics, archive dead entries, and keep it tied to the real plant, or it becomes a museum of how the plant used to run.