Early in my time as a process engineer on a refinery expansion project, I watched a senior colleague spend three days on what looked, from the outside, like a simple task: updating the downstream documents after a single P&ID revision. The change itself took perhaps 40 minutes. The consequence of that change, the finding and fixing of every downstream document that referenced the affected tag, took the rest of the week. I remember thinking that this could not be normal. It was completely normal.
A P&ID revision is not a self-contained event. It is an upstream trigger that propagates obligations through every discipline that works from P&IDs as a reference. Understanding the shape and cost of that propagation is the first step toward managing it.
What a P&ID Revision Actually Contains
P&ID revisions are issued under a document number and revision code (Rev A, Rev B, Rev 0, Rev 1, and so on depending on the project's coding convention). Each revision contains a cloud marking the changed area and a revision register block noting what changed, who approved it, and when. That metadata is the only formal record of what the revision touched.
What the revision register does not tell you is which downstream documents need updating as a result. That information exists nowhere in a structured form. It lives in the heads of experienced engineers, cross-referenced manually during review meetings, or discovered after the fact during HAZOP or detailed design checking sessions.
The revision could be as small as changing a valve tag from HV-201 to HV-201A due to a tag numbering conflict, or as large as revising the operating pressure of an entire process section. In both cases, the same discovery problem applies: every downstream document that mentions HV-201 needs to be found and corrected.
Tracing a Single Tag Change Through the Document Set
Consider a concrete example from a gas compression facility FEED package. Revision R4 to P&ID sheet 12B changes the design operating temperature for the suction drum inlet from 45 degrees C to 52 degrees C, driven by updated feed composition data from the reservoir engineering team. The tag in question is temperature transmitter TT-304.
That one change generates update obligations across at least the following documents:
| Document | Attribute Affected | Old Value | New Value | Update Owner |
|---|---|---|---|---|
| Instrument Datasheet TT-304 | Process temp (design) | 45 deg C | 52 deg C | Instrument Engineer |
| Heat and Mass Balance | Suction temp condition | 45 deg C | 52 deg C | Process Engineer |
| Equipment Spec: Suction Drum | Design temp (inlet nozzle) | 45 deg C | 52 deg C | Mechanical Engineer |
| Line List: inlet line 4"-P-3014 | Operating temp | 45 deg C | 52 deg C | Piping Engineer |
| Instrument Index: TT-304 row | Normal process temp | 45 deg C | 52 deg C | Instrument Engineer |
| Control Philosophy | High-temp alarm setpoint basis | Ref: 45 deg C base | Ref: 52 deg C base | Process/Controls Engineer |
| HAZOP Action Register | Consequence ref (high-temp deviation) | Review required | Review required | Process Engineer |
Seven documents, five different document owners, two different disciplines who do not share a common filing system. Each update is individually straightforward. Coordinating the updates and verifying that all seven have been completed correctly, with the right revision number on each, is where the time goes.
The Cascade Is Invisible Until It Isn't
The difficulty is not that engineers fail to understand the cascade. Most experienced process and instrument engineers have an intuitive model of which documents are interconnected. The problem is that this model is not encoded anywhere that the whole team can inspect.
During FEED, with a lean team of perhaps eight engineers on a single package, the model in someone's head is often sufficient. The same people review each other's documents and catch the inconsistency during a cross-check meeting before the revision is issued for client review. The system works through familiarity.
During detailed design, with a larger team, multiple sub-contractors feeding into the same document set, and revision cycles happening across several P&ID sheets simultaneously, the informal model breaks down. An instrument engineer updating TT-304's datasheet has no automated way to know that the piping team's line list for line 4"-P-3014 also references the operating temperature, or that the control philosophy document contains a note derived from the same value.
Why the Week Disappears
When I traced how that week-long rework effort actually divided, the pattern was consistent: about 20% of the time went to finding the right revision of each document (EDMS navigation, folder structures, email attachments), about 35% went to the actual cross-checking and annotation, and the remaining 45% went to chasing confirmation that the other discipline engineers had made their updates and issuing the corrected versions for re-transmittal.
The confirmation chase is the most wasteful segment. An experienced engineer spends their afternoon sending emails to four colleagues asking whether a specific field on a specific document has been updated yet. The colleagues are themselves in the middle of other tasks. Response latency adds half a day. A follow-up email adds another few hours.
At the end of this process, there is still no reliable confirmation that every document was updated. There is only the absence of a known discrepancy. Those are not the same thing.
What Happens When a Cascade Is Missed
Missed cascades accumulate quietly until they surface in a context where fixing them is expensive. A common surface point is during HAZOP: the process engineer presents the HAZOP team with the current P&ID and current operating conditions, and a design engineer catches a discrepancy between the stated operating temperature and what the equipment specification says. The HAZOP is paused while the discrepancy is resolved. Depending on its significance, this can push the HAZOP schedule by half a day.
A more costly surface point is during detailed design drawing check: a piping stress engineer uses an operating temperature from a line list that was never updated after the P&ID revision, performs the stress analysis, and issues the isometric drawings. The error is found during a final IFC check or, in the worst case, during fabrication when someone compares the isometric to the P&ID. At that stage the fix requires not just a document update but a re-analysis and re-issue of affected drawings.
We are not saying that every P&ID change generates this level of rework. Cosmetic changes (tag number corrections, drawing note wording, minor symbol adjustments) rarely cascade significantly. The problem is concentrated in functional changes to operating conditions, flow paths, control logic basis, or safety setpoints. In a typical FEED-to-detailed-design project, those functional changes occur regularly and are not always clearly distinguished from cosmetic changes in the revision register.
A Systematic Approach to Cascade Tracking
The underlying requirement is simple to state: when a value on a P&ID changes, every downstream document that references that value should be identified immediately, assigned to an owner, and tracked to completion. What makes this hard in practice is that the linkage between an upstream P&ID value and its downstream appearances is not captured in any standard EPC document format.
Some teams build spreadsheet cross-reference tables manually: a matrix of tags down one axis and downstream documents across the other, with cell entries indicating which documents contain a reference to each tag. This works when it is maintained carefully. It becomes unreliable as soon as someone issues a revision without updating the matrix, which happens frequently under schedule pressure.
What would actually help is a system that reads the document set and builds this cross-reference automatically, updating it each time a new document revision is uploaded. The cascade would then be visible as a structured list, not as a mental model that relies on an engineer's memory of which documents they worked on six weeks ago. That is precisely the gap that led us to build SnapScale, and the problem that shaped every design decision we made about how the system should work.