Preparing a technical document pack

When a valve enquiry finishes, the knowledge from it exists in one place: a thread, in one person's mailbox. Six months later that person is on holiday and somebody has to reorder. This is the point at which most of the work gets done again.

A document pack is the cheap insurance. It is not a report and nobody needs to write prose for it. It is a folder with a predictable shape.

What goes in

• The requirement, final versionOne file, versioned. Not the thread it evolved in.
• The exact model designationsWritten as text, not only inside a PDF. This is what the next person will search for.
• The photographsNamed so they say what they show. Markings, connections, the whole valve.
• What was confirmed, and by whomA short list: the question, the answer, the date, the source. This is the most valuable file in the pack and the one most often missing.
• What was NOT confirmedEqually valuable. An open question recorded as open saves the next person from assuming it was settled.
• The documents receivedCertificates, drawings, datasheets, with their revisions in the filenames.

Two rules

Two rules keep a pack usable. Filenames carry the model designation and the revision, because a folder is searched by name far more often than it is browsed. And nothing is edited in place - a corrected file arrives as a new revision alongside the old one, so that a decision made last month can still be traced to the information it was made on.

That second rule feels like clutter until the first time somebody asks why a part was specified the way it was.

Asking in a form you can file

Where ANYI fits into this: everything we confirm for you is confirmed against an exact model designation, so it can be filed against that designation and found again. If you tell us you are building a pack, we will answer in a form you can file - the question restated, the answer, and what it is based on - rather than in a paragraph you would have to summarise.