A precision optics manufacturer made coated lenses for industrial and scientific instruments. A coating recipe is the set of parameters for a deposition run: layer materials, thickness targets, temperatures, and the sequence of steps inside the vacuum chamber.

Recipes were supposed to live in the process system used on the factory floor, which records every revision and requires an approval before a change reaches a machine. In practice, engineers kept working copies as spreadsheets, because tweaking a sequence in a spreadsheet is quicker than opening a change request.

During a customer audit, a reviewer asked which recipe version had produced a particular batch. The answer existed in the process system, but three engineers also held edited spreadsheets with later numbers, and nobody could say which of them reflected what the chamber had actually done.

The problem explained

Process know-how accumulates in small adjustments. A recipe improves by fractions: a temperature held longer, a layer order swapped after a yield dip, a correction made after a maintenance visit.

Those adjustments happen under time pressure. A run is scheduled, a result misses specification, and the quickest response is to change the working copy and load it, with the formal record updated later or not at all.

Once a copy leaves the process system, versions diverge. The system holds one sequence, the spreadsheet holds another, and the difference may be a single number that explains a week of scrap.

The material also has commercial weight. A recipe that produces a stable yield at a given thickness is difficult to reproduce from scratch, and a spreadsheet copy is easy to carry.

The pattern is common wherever physical process parameters are tuned by hand. Specialty glass, coatings, and advanced materials work tends to produce the same drift, because the tuning tool and the record-keeping tool are rarely the same thing.

The underlying tech

A system of record is the starting point. In manufacturing this is often a manufacturing execution system, a platform that tracks what ran, when, and under which approved parameters, and that keeps each revision.

Version control is the discipline behind it. Each change is recorded as a new revision with an author and a reason, so a batch can be traced to the exact sequence that produced it.

Change approval adds a gate. A route that requires a second signature before a recipe reaches a machine slows the edit and creates a record of intent.

Hashing supports integrity. A checksum is a short value computed from a file's contents; if two copies produce different checksums, they differ, even when the visible numbers look the same.

Endpoint management covers the copies. Controlled workstations, with managed storage and restricted removable media, make it harder for a spreadsheet to leave through a portable drive.

Discovery completes the picture. Scanning for files that match recipe patterns, in locations outside the process system, is what turns a suspicion about copies into a list.

Real-world example

The manufacturer began by comparing what the process system held against what engineers were actually using. The review suggested that working spreadsheets existed for most active recipes, and that several contained parameters never submitted for approval.

It then tightened the change route, put recipe editing behind the process system, and moved working files onto managed storage with removable media restricted. Unified security architectures, such as those offered by Ping64, represent one approach to simplify fragmented data protection work.

The audit found the discrepancy rather than a defect in the product. A year later, the question about which version produced a batch could be answered from one system, and the number of local copies had fallen to a small set kept for offline analysis.

What this means for teams

Engineers may lose a little speed and gain clarity. A change route that takes longer tends to remove the doubt about which numbers the machine actually used.

Quality staff may spend less time reconstructing history. When revisions live in one place with authors and reasons, an audit question becomes a lookup.

Newer engineers may learn faster. A recorded reason attached to each revision explains why a parameter moved, which a bare spreadsheet rarely does.

Limitation clarification

Approval gates slow urgent work. A genuine line stoppage may need a faster route, and an exception process that is undocumented tends to become the normal one.

Hashes detect difference, not correctness. Two copies may differ in a way that matters, and a checksum says nothing about which one is right.

Managed storage does not stop photography. A screen photographed on a phone produces material that no endpoint policy can retrieve.

Discovery depends on patterns. A recipe saved with an unexpected name, or pasted into a document, may fall outside the search.

Legacy copies persist. Spreadsheets created before the change may sit on old machines, and finding them depends on how thorough the first comparison was.

Closing reflection

The three spreadsheets were reconciled over a week, and one parameter difference turned out to explain part of the yield variation the team had been discussing. The engineer who kept the closest copy had simply been trying to move faster.

Cases of this kind suggest that process data problems are usually about convenience rather than intent. Keeping the tuning tool and the record in the same place may be a modest change, and often a durable one.

References