Documents, and who is still holding the old one

What it is, and what it is not

A vault holding files with revision semantics, check-out locking, approval state, and controlled distribution — plus the machinery underneath that makes large files behave: chunked resumable upload, content-hash deduplication, delta transfer, signed URLs, storage tiering and orphan collection.

It is not a folder tree with permissions. The difference is that a document here is an object with the same revision and lifecycle semantics as a part, governed by the same change process, and connected into the same relationship graph.

It is also not a place to put attachments. An attachment on a record has no revision, no approval state, no controlled copy and no way to answer which version was current when a part shipped. For an informal team that is fine; for anyone facing an audit or a warranty claim it is the gap that costs money.

The mechanism: controlled copies are tracked, not just watermarked

Watermarking a PDF is the easy half and most tools stop there. The half that matters is the register: which copies were issued, to whom, at which revision, when, and until when.

Every controlled copy carries a recipient, an issue date and an expiry, stamped into the file itself so a printout on a bench declares its own status. Expiry is not decoration — an expired copy is reported as expired, so the drawing taped up eighteen months ago stops being ambiguous.

When a new revision releases, every outstanding copy of the previous one is marked superseded and its holders are named. That converts the worst question in document control — who is still working from the old drawing — from a guess into a list. Suppliers reached through the portal see the shared revision directly and never hold a copy at all, which is strictly better where it is possible.

Underneath, a released revision cannot be edited. Not by an author, not by an administrator. That is what makes the register meaningful: a copy issued at rev C corresponds to a rev C that still exists and has not moved.

The failure it prevents

A contract manufacturer builds to a drawing issued in July. In September a change releases and the drawing revises. Somebody emails the new PDF.

The email goes to a person who has since changed roles. The old PDF is still in the shared folder the production supervisor actually opens, and it looks exactly like the new one because nothing on the page says which revision it is or when it stopped being current. Four hundred units are built to the old geometry.

Nothing here was negligent. The failure is that the distribution was a copy operation rather than a controlled one, so nobody could enumerate who held what. A register plus an expiry stamp on the artefact itself is the whole fix, and it is unglamorous enough that most tools skip it.

How it meets the rest of the product

Documents attach to parts, changes, suppliers, requirements and quality records as typed relationships, so a drawing is reachable from the part it specifies and the part is reachable from the drawing. Impact analysis traverses those edges, which is why a part change surfaces the specifications that describe it.

Document revisions move through change control exactly as part revisions do — the same seven change kinds, the same approvals, the same effectivity, the same atomic release. A drawing does not get its own parallel process, because two revision schemes that disagree at the boundary is how a PLM ends up with a part at rev C referencing a drawing at rev E that nobody can reconcile.

Markup and annotation live on the document rather than in email, and redlines attach to the change that proposes them. The vault handles PDF and image viewing directly; CAD models stay in the CAD system with a reference here.

Full-text search covers document content, filtered at query time by the same permission clause everything else uses, so a document you may not see does not appear in a count.

How it meets your ERP

Documents largely do not go to the ERP, and that is the correct arrangement. What the ERP needs is a reference — the drawing number and revision associated with an item — not the file, because an ERP is not a document control system and treating it as one produces two registers that disagree.

Where a connector exposes a document link field, Manufacturing PLM populates it with the number, the revision and a signed URL that resolves to the current controlled view. A person clicking from the ERP lands on the live revision rather than on whatever was copied there once.

Nothing flows the other way. If your ERP holds attachments today, they stay there; Manufacturing PLM does not attempt to absorb them, because a half-migrated document estate is worse than two clearly separated ones.

Where the boundary is

Manufacturing PLM is not a CAD vault for desktop tools in the PDM sense. Native files check in with revision and check-out locking, but there is no add-in, no live metadata read from the model, and no derivative or visualisation pipeline. Cloud CAD connects over its API instead.

There is also no in-app 3D viewing and no geometry comparison. PDF and image viewing with markup are handled; comparing two revisions of a model is a question for the CAD system, and Manufacturing PLM links out rather than rendering it worse.