Rev C is approved. Which Rev C?

Document control sends the transmittal letter: Rev C approved for release. Everyone opens the folder and trusts the stamp.

Monday, the one-line diagram is exported to PDF showing pump P-101A. Electrical opens that PDF, reviews it, and stamps it approved. Tuesday, the process engineer swaps P-101A for P-101B in the native file, a real and correct change. Nobody re-exports the one-line, so the PDF sitting in the submittal folder still shows P-101A. Friday, document control bundles the folder and labels it Rev C.

The approval stamp on that one-line is real. Electrical did review it, on Monday, before the pump changed. So Rev C ships with an approved drawing that shows the wrong pump, and nothing in the folder tells anyone the approval is a day older than the design.

How approvals get ahead of the files

Nobody is trying to cheat the system. Reviews happen in parallel. Exports happen when someone has a window. Email threads carry the real state: "Electrical is good on the set from the 14th, waiting on updated GA." The transmittal register says Rev C. The register is what the customer sees.

• Different disciplines approve exports taken on different days.
• A late edit in Word or Excel does not invalidate stamps already on last week's PDF.
• PLM or document control records status at the package level, not per file hash.
• Intermediate revisions never get a formal re-review, only the delta someone remembered to mention.

An approval without a pinned file revision is a opinion, not a record.

What auditors actually ask for

When something goes wrong on site (wrong valve trim, wrong relief setpoint), the post-mortem is never "who read the PDF." It is "show me exactly which revision each approver signed, on which date, for which transmittal." Teams that live in Bluebeam sessions and SharePoint folders spend days reconstructing that story from screenshots and forwarded emails.

Good release practice ties every approval to a specific revision of every file in the session, not a letter grade floating above the folder. That is the difference between document control (tracking status) and document-set change management (tracking what changed, who saw it, and what went out the door together).

How Kord pins the revision

• Kord ties every approval to a specific file version inside the review session. Swap P-101A for P-101B and that's a new version; the old stamp does not carry forward to it.
• A release is a named snapshot of the exact revisions that were approved, so "Rev C" resolves to one set of files, not a letter floating above a folder that kept changing.
• Version history shows which revision each discipline signed and when, so the post-mortem question — show me exactly what mechanical approved on the 14th — is a lookup, not a week of forwarded emails.
• Because every discipline reviews against the same cut, electrical can't approve Monday's one-line while Tuesday's pump swap lands in the native file without that showing up as a newer version awaiting review.
• The release step surfaces open items, so a package can't go out marked approved while one file is still mid-edit.