In a fireproof cabinet in the corner of the quality office at a mid-market machine shop, there are roughly forty thousand paper travelers going back nine years. A traveler is the printed sheet that rides with a job through the plant: the part number, the operations, the operator initials, the inspection stamps, and the handwritten notes in the margin where a setup man scrawled "ran hot, slowed feed to 80%" or "third pin gage out, used backup." Nobody reads them. They are kept because the customer's quality standard, IATF 16949 (the automotive quality management standard the customer audits the plant against), requires retention, and for no other reason. When a recurring porosity defect showed up on a cast aluminum housing last spring, the quality engineer spent three days building a fishbone diagram from the memory of two operators and a supervisor. The answer he needed was already written down. It was in eleven of those travelers, in a margin note that said "porosity worse on the parts poured right after lunch restart," repeated across two years and three different operators who never spoke to each other. The tribal knowledge was not lost. It was filed. This lesson is about the difference, and about how a thinning crew can finally read what it already wrote down.

The Knowledge That Was Written but Never Read

There is a comfortable myth on the floor that tribal knowledge lives only in people's heads, that the only way to capture it is to interview Dave the inspector before he retires in November. That myth is half true and half dangerous. A great deal of what looks like tribal knowledge was, in fact, written down at the moment it happened, in the place where it happened, by the person who saw it. It just landed somewhere nobody ever looks again: the margin of a traveler, the comment field of a work order in the CMMS (Computerized Maintenance Management System, the software that holds every maintenance work order and repair note), the free-text disposition on a nonconformance report, the operator's daily log, the shift handover notebook, the scribbled cause on a downtime ticket.

The reason nobody reads it is not laziness. It is volume and shape. Forty thousand travelers is not a document a human can read. Nine years of CMMS history might hold sixty thousand work orders, each with a one-line description a tech typed in a hurry: "bearing noise drive end, greased, monitor" or "VFD fault F12 again, reset, ran ok." No quality engineer is going to read sixty thousand of those. And even if one did, the patterns that matter are not in any single record. They are in the repetition across hundreds of records, the same complaint appearing every few weeks on the same asset, the same margin note clustering around the same shift or the same material lot. A human reading one record at a time cannot see a pattern that only exists across five hundred of them.

This is exactly the shape of problem that a large language model is good at, and it is worth being precise about why. The model is not going to know your plant. It has never seen your housing or your press. What it can do, given the actual text of your records, is read all of it without getting tired, normalize the messy shorthand into consistent categories, and surface the clusters and repeats that a human would need months to find. The work is not the model inventing knowledge. The work is the model reading what your people already wrote, faster than any human could, and handing back the patterns for a human to verify.

Most tribal knowledge was not lost. It was written down once, in the margin, and never read again. Mining is reading at a scale a human cannot.

Getting the Records into a Shape the AI Can Read

Before any pattern-finding happens, the records have to become text the model can actually take in. This is the unglamorous half of the work, and skipping it is the most common reason a mining project produces garbage. There are two cases: paper and digital, and they are very different jobs.

The paper case: travelers, inspection sheets, and logbooks. Those forty thousand travelers are images of handwriting and stamps, not text. They have to be scanned and run through OCR (Optical Character Recognition, the technology that turns an image of text into machine-readable characters). Handwriting OCR in 2026 is far better than it was, but it is not perfect, and a margin note that says "feed .004 IPR" can come back as "feed 004 1PR" if the scan is poor. The honest math here matters: if you have 40,000 travelers and OCR runs at 92% character accuracy on handwriting, you do not have clean data, you have data with an error in roughly one of every twelve characters. For finding broad patterns ("porosity" appears a lot near "lunch restart") that is good enough. For pulling an exact torque spec or feed rate out of a margin, it is not, and you must verify the specific number against the source image every time. Treat OCR output as a search index that points you back to the paper, never as the system of record.

The digital case: CMMS, MES, and quality-system exports. Here the text already exists, but it is trapped in a database and shaped for a machine, not a reader. The MES (Manufacturing Execution System, the software that tracks production orders, run data, and quality results on the floor) and the CMMS will both export to a spreadsheet or a flat file. The free-text fields are what you want: work-order descriptions, failure codes, repair notes, nonconformance dispositions, operator comments. Pull those, plus the structured columns that give them context: asset ID, date and time, shift, part number, material lot, operator or tech ID. The structured columns are what let the model say "this cluster is concentrated on second shift" instead of just "this complaint repeats."

A worked example on cost, because this is where plants flinch. A quality engineer at a plant with 40,000 travelers might fear an enormous bill. In practice the digital exports are nearly free to prepare, and the paper scanning is the real expense. Scanning a traveler at a service bureau runs about 8 to 12 cents per page; 40,000 single pages is roughly 4,000 dollars one time. Running the resulting text through a model to categorize and cluster it is a few hundred dollars of compute, not thousands, because you summarize and tag in batches rather than asking the model to reason about every page individually. Set against three days of a quality engineer's time burned on one fishbone, at a loaded rate near 75 dollars an hour, that single avoided exercise is about 1,800 dollars. The mined index pays for the paper scan in roughly two avoided fishbones, and then keeps paying.

Finding the Pattern, Not Inventing It

Once the text exists, the actual mining is a sequence of asks, each narrower than the last, and each one a thing the model can do safely because it is reading, summarizing, or counting, not deciding. The cardinal discipline of this whole lesson is that you keep the model on tasks where it cannot hurt you: read, group, count, and quote back. The moment you let it explain why, you have left mining and entered guessing, and a guessed root cause is exactly the hallucinated-cause failure mode this program warns about.

Step one: normalize the vocabulary. Across nine years and forty operators, the same problem gets written forty ways. "Porosity," "pinholes," "gas," "voids," "bubbles," and "swiss cheese" may all mean the same defect. The first job is to have the model read the free text and propose a normalized category list, then map every record to one category. You review the category list (this is a five-minute human task) before anything is counted, because if the model lumps "porosity" with "surface contamination" your counts are wrong from the start. This is a worked example of keeping the human on the judgment and the model on the labor.

Step two: count and rank. With clean categories, you get a Pareto: which defect or failure repeats most, on which asset, on which part. A Pareto is the bar chart that ranks problems by frequency so you work the tallest bar first. The model can build the counts; you read the chart. In the porosity example, the count showed the housing porosity NCR (Nonconformance Report, the quality record opened when a part is found out of spec) was the third most frequent quality event over two years and the single most frequent on that part number, which is the kind of fact that reorders a plant's improvement list immediately.

Step three: cross-tabulate against the context columns. This is where the gold is. Take the top cluster and break it down by shift, by material lot, by day of week, by time of day, by operator, by tool or die ID. The porosity cluster, cross-tabbed against time of day, lit up in the first hour after every break: the lunch restart and the shift-start restart. That correlation was in the data the whole time. No single record contained it. It only appeared when six hundred records were grouped by time-of-day.

Step four: pull the human notes for the cluster. Now, and only now, you have the model retrieve the actual margin notes and repair comments for the records in that cluster and quote them back to you verbatim. This is retrieval, not generation: you want the operators' real words, with the traveler or work-order number attached, so you can find the source. Eleven travelers carried a variant of "worse right after restart." That is not the model's theory. That is what eleven humans independently wrote, surfaced together for the first time.

Notice what the model did and did not do. It read, normalized, counted, cross-tabbed, and quoted. It did not say "the cause is the die cooling during the break and the first shots running cold." A human metallurgist says that, looking at the surfaced pattern, and then proves it with a controlled run. The model handed the human a sharp hypothesis in an afternoon instead of three days. The human still owns the cause.

The CMMS Goldmine: Recurring Failures Hiding in Plain Text

The travelers are the quality goldmine. The CMMS is the maintenance one, and it is often richer because the entries are digital from the start. Every reactive repair a tech ever logged is a sentence about how a machine actually fails, written by the person who fixed it. Mined together, those sentences are the predictive-maintenance training data the plant thinks it does not have, and they are also a brutal honest history of which assets eat the schedule.

Consider the hot-afternoon breakdown that defines the goldmine of this whole program: the one machine that always fails when it is hot. In a raw CMMS that belief is folklore, the kind of thing a veteran tech says and a new tech has no reason to trust. Mine nine years of work orders for that asset, normalize the failure descriptions, and cross-tab by month and by logged ambient or by outdoor temperature, and the folklore becomes a chart. Suppose the mining shows that asset 4471, a hydraulic press, generated 38 unplanned-downtime work orders over the period, and 27 of them fell in June, July, and August, clustered on the afternoon shift, with repair notes repeatedly mentioning "hydraulic over-temp fault" and "oil hot, topped off, reset." That is the hot-afternoon breakdown, proven from the plant's own records, with a clear hypothesis (cooling capacity on the hydraulic unit is marginal in summer heat) that a reliability engineer can act on.

The dollar case writes itself here, and it is the kind of number that funds a whole training cohort. If each of those summer over-temp events costs the line two hours of downtime, and the line runs at a contribution margin of 900 dollars an hour, 27 events at two hours is 54 hours, roughly 48,600 dollars of lost production traced to one mined pattern on one asset. A 1,500 dollar auxiliary oil cooler and a revised summer preventive-maintenance interval, surfaced because someone finally read the work orders, is the cheapest 48,600 dollars a plant will ever recover. None of that required new sensors or a predictive model. It required reading the maintenance history the plant had been keeping for nine years and never querying.

A second CMMS pattern worth mining: the repeat repair that never sticks. Group work orders by asset and look for the same failure description recurring at a short interval. A bearing greased four times in six months is not a maintenance success; it is a misalignment or a contamination problem that the grease is masking. Mining surfaces these "treating the symptom" loops because the same short phrase keeps reappearing on the same asset. Each loop is an MTBF problem (Mean Time Between Failures, the average run time between breakdowns, the core reliability number) hiding behind a tech doing exactly what the last work order told him to do.

Where Mining Goes Wrong

Mining historical records is high-ROI, but it has specific failure modes, and a practitioner who does not know them will confidently produce a wrong answer dressed up in a chart. Each of these is a place where the human stays in command.

Survivorship and reporting bias. The records are not reality. They are what got written down. If second shift never bothered to log minor jams because the supervisor discouraged "small stuff" on the downtime sheet, the mined Pareto will understate second-shift jams, and you will chase the wrong bar. Before you trust a count, ask whether the absence of a record means the thing did not happen or just that nobody wrote it. The fix is to validate a surprising pattern against a second source: actual scrap weight, the historian, or a week of deliberate observation.

OCR drift on the numbers. As covered earlier, handwriting OCR is fine for words and dangerous for digits. If a mined pattern hinges on a specific value, a feed rate, a torque, a temperature, you must open the source image and read the human's actual handwriting before you act. A worked horror story: a mined "pattern" of low torque on a fastener turned out to be OCR reading "45" as "15" across a batch of legible but cursive sheets. The pattern was a scanning artifact, not a process problem. One look at the paper killed it.

Correlation paraded as cause. The model surfaces that porosity correlates with the lunch restart. It is tempting, and wrong, to write "lunch restart causes porosity" on a corrective-action report and ship it to the customer. Correlation is a hypothesis, not a root cause, and the customer audits the root cause. The mined pattern earns you a controlled experiment: run the next deliberate restart with the die held warm and measure the porosity. If it drops, you have a cause. If it does not, the correlation was hiding a third factor, perhaps a material lot that always happened to be loaded after lunch.

Enshrining a myth because it is written down a lot. Repetition in the records is not truth. If forty operators were all trained by one person who believed a wrong thing, the wrong thing will appear forty times and look like strong evidence. Frequency in the source text tells you what people believed and did, not what was correct. This is why the next lesson in this chapter, on verifying captured knowledge, exists: a pattern mined from records is a candidate for truth, validated against data and a second expert before it is taught to the next shift.

Turning a Mined Pattern into Something the Plant Keeps

A pattern found and then forgotten is worth nothing. The point of mining is to convert a one-time discovery into a standing asset the thinner, greener crew can use on every future shift. That conversion has a shape, and it is the bridge between this lesson and the structured-output and knowledge-base work later in the program.

Write the pattern as a verified, sourced entry. Each confirmed pattern becomes a short structured record: the symptom in normalized terms, the conditions it clusters under, the confirmed or hypothesized cause, the corrective action, and, critically, the source records by number so the next person can audit it. "Housing porosity clusters in the first hour after a line restart; controlled trial confirmed die temperature is the driver; counter-measure is a warm-up shot sequence after every break; evidence: NCRs 2024-0118 through 2024-0411, eleven travelers, controlled run 2024-05." That entry is now part of the plant's institutional memory, not one engineer's recollection.

Feed it forward into the live systems. The normalized failure categories you built for mining are the same categories the CMMS should use going forward, so tomorrow's work orders are minable without OCR. The mined hot-afternoon pattern becomes a seasonal preventive-maintenance task with a due date. The porosity counter-measure becomes a line in the work instruction. Mining is not a one-time archaeology project; done right, it reshapes how the plant records the next nine years so the data gets richer instead of staying messy.

Keep the human signature on every published conclusion. Remember the cardinal rule of this entire program: the customer audits you, not the vendor, and not the model. When a mined pattern becomes a corrective action that goes to a customer, a named engineer signs it, having verified the cause with a controlled trial, not because "the AI found a correlation." The model is the fastest research assistant the plant has ever had. The accountability for what gets published from its findings stays exactly where it always was, with the human who put their name on the record.

Key Takeaways

• Most tribal knowledge was not lost; it was written down once, in a traveler margin or a CMMS comment, and never read again. Mining is reading those records at a scale and consistency no human can match.
• The work the model does safely is read, normalize, count, cross-tabulate, and quote back verbatim. The moment it explains why, you have left mining and entered guessing, which is the hallucinated-cause failure mode.
• Getting records into shape is half the job. Paper needs OCR and must be treated as a search index that points back to the source image, never as the system of record, because handwriting OCR mangles digits.
• The pattern that matters lives in the repetition across hundreds of records and in cross-tabulation against context columns (shift, lot, time of day), not in any single record. The porosity-after-restart cluster only appeared when 600 records were grouped by time of day.
• Mined CMMS history is the predictive-maintenance data a plant thinks it lacks; the hot-afternoon breakdown can be proven from nine years of work orders, and a 48,600 dollar summer downtime pattern can be fixed with a 1,500 dollar cooler and a revised PM interval.
• Know the failure modes: reporting bias means absent records are not absent events, OCR drift corrupts numbers, correlation is a hypothesis and not a root cause, and a myth written down forty times is still a myth.
• A mined pattern is a candidate for truth, confirmed by a controlled experiment and a second source before it becomes a corrective action a customer will audit.
• Convert every confirmed pattern into a sourced, structured entry, feed the normalized categories forward so future records are minable, and keep a named human signature on every published conclusion.