Common documentation mistakes: the file errors that make good products look unproven

Scope drift is the commonest file error. A test report for one model is filed against another model that shares a name but differs in a safety critical part. A supplier certificate for one material batch is filed as if it covered all batches. A risk assessment written for an early prototype is filed as if it covered the production version.

Preventing scope drift needs a matching discipline: each document should be checked for model, version, batch, and date against the product it is filed for, at the moment of filing. That check takes minutes and prevents a file that collapses under the first serious question. A file whose documents all match its product is a file an authority can trust; a file with one mismatched document invites doubt about every other document in it.

Missing links are the gaps between documents that should connect. A risk assessment names a control, but no test report proves the control works. A test report passes a property, but no document shows which batches the test covered. A supplier change is recorded, but the risk assessment was never updated to reflect it. A complaint reveals a hazard, but the assessment was never revisited.

Linking can be as simple as cross references: the assessment cites the test report by date and scope, the test report cites the batch, the batch record cites the supplier lot, the complaint log cites the assessment update. Those references, written at the time, turn a pile of documents into a file that tells a coherent story. Without them, even genuine work looks disconnected and unconvincing.

Stale versions creep in when a product changes but its file does not, or when a file is updated in one place but not in another. A design change alters a material, but the old material certificate remains. A label is revised, but the file holds the old artwork. A supplier is replaced, but the old supplier's documents remain as if current.

Version control prevents this, in a simple form: each document carries a version and a date, the file carries an index of current versions, and a product change triggers a file review that updates the index. Illustration: a maker of garden tools adds a change log to each product file, listing every design change and the documents updated for it, and stale version findings disappear from its audits.

Evidence is overclaimed when a document is described as proving more than it does. A supplier assurance is described as a test result. A test of one property is described as proving overall safety. A sample test is described as proving every batch. A standard's name is cited without checking whether the product actually meets it.

The cure is precise language. Each document should be described by what it actually shows, its scope, its method, and its limits, in a sentence that a stranger could verify. Precise description feels less impressive than broad claims, but it builds a file that survives scrutiny, while broad claims collapse at the first detailed question.

Filing chaos looks like documents scattered across inboxes, shared drives, and paper folders, with no index and no owner. A document known to exist cannot be found when needed, so it might as well not exist for audit purposes. Chaos also breeds duplication, where different versions of the same document circulate, and nobody knows which is current. The fix is unglamorous: one file location per product, one index, one owner, and a rule that documents are filed at receipt, not at audit time.

Filing at receipt is the key habit. A test report filed the day it arrives, against the correct product and batch, with its scope noted, will be found later. A test report left in an inbox for months, then filed in a rush before an audit, will be misfiled, misdescribed, or lost. The habit costs minutes per document and saves hours per audit, and it is the difference between a file and a pile.

Reviewing your own file means reading it as a stranger would: does each document match the product, do the links connect, are the versions current, does each claim match its evidence, and can every document be found from the index? That stranger's reading, done periodically and after any product change, catches most of the mistakes in this guide before an authority does. A review checklist built from those five questions, applied to a sample of files, is a practical audit tool in itself.

The review should end with a short list of fixes, owners, and dates, filed with the review note. A review that produces no fixes is either a perfect file, which is rare, or a superficial review, which is common. The team should welcome a review that finds mistakes, because a mistake found by the team is a mistake fixed cheaply, while a mistake found by an authority is a mistake fixed under pressure.