Document control sends the transmittal letter: Rev C, approved for release. Everybody opens the folder and trusts the stamp. Fair enough. That's what the stamp is for.

Monday, the one-line gets exported to PDF showing pump P-101A. Electrical opens that PDF, reviews it, stamps it. Tuesday, process swaps P-101A for P-101B in the native file, a correct change nobody argues with. Nobody re-exports the one-line, so the PDF in the submittal folder still shows P-101A. Friday, document control bundles the folder and calls it Rev C.

The 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 showing the wrong pump, and nothing in the folder says the approval is a day older than the design it's approving.

How approvals get ahead of the files

Nobody's gaming anything. Reviews run in parallel. Exports happen whenever someone gets a free hour. The real state of play lives in an email thread ('electrical's good on the set from the 14th, still waiting on the updated GA'), and the transmittal register says Rev C. The register is the part the customer sees.

• Two disciplines approve exports that were taken on different days.
• A late edit in Word or Excel doesn't un-stamp last week's PDF.
• PLM and document control record status at the package level, not per file.
• The in-between revisions never get a real re-review, just whatever delta someone thought to mention in the email.

A stamp that isn't tied to a specific file revision is really just a note that someone looked at something, once.

What the post-mortem actually asks for

When something goes wrong on site (wrong valve trim, relief set the wrong way) the question afterward is never 'who read the PDF.' It's 'show me exactly which revision each approver signed, on what date, for which transmittal.' Teams living in Bluebeam sessions and SharePoint folders lose days reconstructing that from screenshots and forwarded email.

Good release practice ties every approval to a specific revision of every file in the set, not a letter grade floating over the folder. That's the line between document control, which tracks status, and document-set change management, which tracks what changed, who saw it, and what actually went out the door together.

How Kord pins the revision

• Every approval is tied to a specific file version inside the review session. Swap P-101A for P-101B and that's a new version; the old stamp doesn't follow it forward.
• A release is a named snapshot of the exact revisions that were approved, so 'Rev C' resolves to one set of files instead of a letter hovering over a folder that kept moving.
• Version history shows which revision each discipline signed and when, so 'what did mechanical actually approve on the 14th' is a lookup, not a morning of email archaeology.
• Because every discipline reviews against the same cut, electrical can't quietly sign Monday's one-line while Tuesday's pump swap lands in the native file. That shows up as a newer version waiting for review.
• The release step surfaces open items, so a package can't go out stamped approved while one file is still mid-edit.