Cleaning up old exports, so production never builds from revision A

Next to the cut-off saw hangs a clipboard, and on that clipboard sits a print that has been there for a while. The fitter cutting tubes today knows the part and takes his dimensions from the sheet. Craftsmanship, neatly within tolerance. Except that sheet shows revision A, and engineering has moved on to revision C: a cutout was added and a dimension shifted. The part is made perfectly, and still rejected.

The most dangerous drawing in a company is rarely the one with an error in it; it is the outdated version still floating around somewhere. This article is about that floating around: how stale exports come to exist, how you tackle outdated drawings and revision cleanup, and how you keep them from coming back. The strategy in short: one single place to look, overwriting on every new export, and clear agreements about packages that have already left the building. A toolbox like Thundercad automates exactly the step where people get sloppy.

How a wandering revision A is born

Nobody creates an outdated drawing on purpose; they appear as a by-product of normal work. The four usual routes:

• The email attachment. A PDF that was once emailed stays findable in mailboxes forever. Months later someone searches for the order number, finds the email and works from whatever was attached.
• The print on the shop floor. Prints collect in drawers, on clipboards and behind machines. Paper has no version control and raises no alerts; it simply stays put.
• The convenience copy. A set of PDFs on the desktop "for quick access", an extra folder on a USB stick for the supplier, an export in a personal folder. From that moment on, every copy lives a life of its own.
• The duplicate folder tree. Next to the project folder there is still an old network folder from way back, and both are still being filled. Which one leads is known only to whoever set it up.

The common thread: every export is a snapshot. The model and the drawing in Inventor move along with every change; the PDF once made from them quietly becomes untrue at that same change.

Why this is not a model problem

Inside the model and inside Vault the current state is usually well arranged: there is one latest version, with a revision block and a history. How to set that up, which change deserves a new revision letter and how to maintain the revision block, we described earlier in Keeping track of revisions without the chaos. This article is about what happens after that.

Because every export escapes that tidy control. The moment a PDF, DWG or STEP file leaves the model, it travels on unsupervised: to a folder, a mailbox, a printer. So the risk is not in your revision management, but in the gap between re-export and use: the time in which an old snapshot sits somewhere, ready to pass for current.

The cleanup: back to one single place

Cleaning up starts with a decision: from now on there is exactly one place where valid exports live, the same tree for every order or project. What such a tree looks like, so that even a stand-in gets it immediately, is described in An export folder structure everyone understands (even a year from now). With that decision made, the action itself is manageable:

1. Take stock of where exports live right now: project folders, desktops, personal folders, download folders, old network drives.
2. Compare what you find with the current revision in the model or in Vault.
3. Throw stale work exports away. Do not move them to a folder called "old"; that only relocates the problem. The model is your archive, and an export is recreated in seconds.
4. Walk the shop floor: collect old prints from drawers and clipboards, and put current ones back where they are needed.
5. Say the agreement out loud: whatever is not in the fixed tree does not count.

Prevention: overwriting in a fixed tree

The best protection against wandering copies is boring: every new export of the same document lands in exactly the same place, with exactly the same file name. The new version then overwrites the old one, and in that spot there is always exactly one file per drawing: the current one.

That takes two habits. First: no dates, initials or words like "final" in the file names of work exports, because every variation in the name creates a new file next to the old one instead of on top of it. Second: exporting without thinking about the destination. With Export Folder from Thundercad, exports land in your fixed folder structure automatically, in the same place every time. Overwriting then happens by itself, and the single place to look stays clean without anyone having to police it.

Finally, tie the re-export to the release moment: as soon as a change is approved, replace the exports in the tree right away. That shrinks the gap between model and export to minutes instead of days, and makes it unlikely that someone grabs an old version in the meantime.

Sent does not mean gone

That leaves everything that has already left the building. The customer has revision A sitting in his system, the supplier may already be cutting from it. Outside your own network you cannot clean up, so a different strategy applies there: know what you sent and replace it actively.

So treat sent packages differently from work exports. A sent package gets frozen: it carries the revision in its name and stays stored as proof of what you delivered at that moment. If the revision changes afterwards, you send the new package along with one explicit line: this replaces the previous package, discard the old version. If you keep track of which package with which revision went to whom, one glance tells you who needs a message at every change.

Frequently asked questions

Should I keep old exports as an archive?

Work exports, no: the model and Vault are your archive, and an export is recreated in seconds. Only sent packages are kept frozen, with the revision in the name, so you can always look back at what you delivered at which moment.

How do I tell from a loose PDF whether it is still current?

Reliably: you cannot. Which is exactly why the only thing that works is the agreement that there is one single place to look, and that anything outside it does not count. Do make sure the revision is clearly shown in the title block; then comparing against that place takes seconds.

Does exporting into a fixed tree not cost a lot of extra time?

The other way around: it saves time, because nobody has to think about folder choice and naming any more. With Export Folder the fixed tree is even the fastest route, since the destination is already set. You can try it without obligation in the free trial month of Thundercad.