Your P&ID still says 450 psig

The process engineer updates the P&ID. Inlet pressure drops from 450 psig to 120 psig. The change is correct — the customer revised the operating case. The P&ID gets saved, exported to PDF, and uploaded to the submittal folder. Reviewers mark it approved. So far, so normal.

Three weeks later, procurement questions a relief valve datasheet sized for 550 psig. The heat and mass balance still sizes control valves for 450 psig upstream. The Concept of Operations — the document the customer actually reads first — still describes 450 psig inlet conditions in plain language. Nobody lied. Nobody skipped a step. The package just drifted.

Why this happens on almost every project

Engineering deliverables are a set, not a file. A pressure change ripples through P&IDs, vessel datasheets, line lists, relief studies, heat and mass balances, procurement lists, and narrative specs. Teams know this intellectually. In practice, updates happen under deadline pressure: one discipline moves first, others catch up in the next transmittal, and tribal knowledge fills the gaps between.

• Files live in SharePoint or Drive with version numbers, but no one sees semantic drift across the set.
• Bluebeam sessions compare PDFs one at a time — great for markups, weak for package-level consistency.
• PLM tracks parts and CAD files; it was never built for spec packages and submittal PDFs.
• Document control records status and approvals, not whether the Concept of Ops matches the vessel MAWP.

The four documents that still had the old number

In a typical package after a single pressure revision, these are the usual suspects:

• Concept of Operations — narrative text still cites 450 psig inlet pressure.
• Vessel spec V-301 — MAWP still shows 550 psig while operating pressure moved to 120 psig.
• Heat and mass balance — valve CV sized for 450 psig upstream; flow rates no longer match the revised case.
• Procurement list — material grade may be over-spec for the reduced pressure (SA-516 Gr.70 when a lower grade would suffice).

Each item is fixable in an afternoon. Catching them after customer review costs weeks — and credibility.

What good looks like before release

High-performing teams treat the document set like a system under test. When a driving parameter changes — pressure, temperature, material, equipment tag — they ask one question: what else still references the old value? That check used to mean senior engineers scanning folders from memory. It does not scale across site forks, customer variants, and fast-turn submittals.

The workflow we built Kord for: sync the changed files, run cross-document consistency checks (including AI-assisted reads across specs and calculations), group everything into a structured review session with visual diffs per format, and release with an audit trail that ties approvals to a specific revision set — not a scattered email thread.

A checklist you can use today

• List the driving parameters that changed (pressure, temp, flow, tag renames).
• Search the full submittal folder for the old values — not just the file you edited.
• Require a second reviewer from a different discipline to confirm downstream docs.
• Do not treat PDF export as the end of version control; treat it as a snapshot of a set.
• Log which revision of which file each approval covered.

If your team runs base designs across multiple sites, the checklist breaks down without tooling. That is the gap between file storage and PLM — document-set change management with visual diffs and consistency checks before the customer sees 450 psig in a document you thought was dead.