The process engineer drops the inlet from 150 psig to 120. It's the right call; the customer revised the operating case last week and the number has to come down. So the P&ID gets updated, saved, exported to PDF, dropped in the submittal folder. Reviewers stamp it. Nothing about that is wrong.

Three weeks later the customer opens the Concept of Operations, which is the first thing they actually read, and it still says 150 psig at the inlet. Everything with a real number on it had already moved: the P&ID, the datasheets, the heat and mass balance, all 120. But the narrative spec got updated last, by someone in another discipline, and it kept the old figure. One document out of a couple dozen didn't get the memo. Nobody did anything wrong, exactly. A file just drifted.

Why it happens on nearly every project

A deliverable is a set, not a file, and everyone knows that in the abstract. A pressure change touches the P&IDs, the vessel datasheets, the line list, the relief study, the heat and mass balance, procurement, and the narrative spec that describes all of it in prose. In practice the update happens under a deadline. One discipline moves first, the others catch it on the next transmittal, and whatever falls in the gap gets held together by whoever remembers it changed.

• SharePoint and Drive version the files, so you know something changed. Neither one notices that the number inside two of them no longer agrees.
• Bluebeam is great for a redline, but it compares one PDF to one PDF. It was never going to tell you the package disagrees with itself.
• PLM tracks parts, BOMs, and CAD. Spec packages and submittal PDFs were never its job.
• Document control logs status and approvals. It doesn't read the Concept of Ops and check it against the vessel MAWP.

Where the old number is hiding

After a single pressure revision, the usual suspects in the package:

• Concept of Operations: the prose still cites 150 psig at the inlet.
• Vessel V-301 datasheet: MAWP reads 150 while operating pressure has moved to 120.
• Heat and mass balance: the control valve Cv was sized around 150 psig upstream, so the flows quietly stopped matching the revised case.
• Procurement list: the plate spec may now be over-spec for the lower pressure, SA-516 Gr. 70 where a cheaper grade would have done the job.

Every one of these is a ten-minute fix in the file it lives in. Found after the customer's review, it's a resubmittal and an awkward phone call.

What good teams do before release

The teams that don't get burned treat the set like something under test. When a driving parameter moves (pressure, temperature, a material, an equipment tag) somebody asks the boring question: what else still points at the old value? That used to be a senior engineer scanning folders from memory, which works right up until you're running the same base design across four sites with three customer variants and a submittal due Friday.

That check is the reason we built Kord. Sync the changed files, run consistency checks across the whole set (including AI reads across specs and calcs, not just filename compares), pull everything into one review session with a visual diff per format, and release with an audit trail that ties the approval to a specific set of revisions instead of a folder that kept changing after export.

How Kord catches the drift

• The consistency check reads the whole set (Concept of Operations, vessel datasheet, heat and mass balance, procurement) and flags anything still carrying 150 psig after you drop the inlet to 120.
• Every format gets a native diff, so the change shows up as a marked cell in the heat and mass balance, a clouded region on the P&ID, and a redline in the spec, not a vague 'this file is newer.'
• All the touched files land in one review session, so a second discipline signs off on the downstream docs before release instead of three transmittals later.
• Each approval is pinned to a specific file revision, so 'approved' means a named snapshot of the set, not a PDF that kept moving after someone exported it.
• It syncs on top of the SharePoint or Drive folder you already have, so none of this means relocating a single file.

If you run one base design across several sites, scanning folders from memory stops scaling somewhere around the second or third fork. That gap, between storage that holds the files and PLM that holds the parts, is document-set change management: the visual diff and the consistency check that catch 150 psig in a document you were sure was dead, before the customer does.