Revision control from IFD to as-built

On an EPC project, a P&ID or a piping isometric is issued many times before anything is built from it. It goes out for design, for review, for HAZOP and for construction, then comes back from the field covered in redlines. Every issue changes something. The revision block records that a change happened. It does not always record what changed.

Revision control is the discipline of knowing exactly what differs between two issues of the same document, and of carrying that knowledge into the change notice, the variation claim, the owner's management of change and, finally, the handover. This is a field note on how that works today, where it breaks, and what a structured diff changes.

The issue stages, and what each one promises

Issue codes vary by company and by project, and on any given job the document control procedure is the authority. Most EPC projects use some version of the same stages, each making a promise to a different reader.

• Issued for Design (IFD). The document is stable enough for other disciplines to build on: piping starts layout from the P&ID, instrumentation starts its index, electrical its load list. A change after IFD lands in other people's work.
• Issued for Review (IFR). The document goes to the owner, or to an internal checker, for comment, sometimes more than once. How those comments are dispositioned shapes much of what follows.
• Issued for Construction (IFC). The document is released to fabricate and build from. Spools get cut and supports get welded. A change after IFC costs material and field labor, not just engineering hours.
• As-built. The document is updated from field redlines and survey to show what was actually installed. Operations, maintenance and the next project will all rely on it.

Many projects add issues for approval, purchase and HAZOP, and a common convention letters revisions before IFC and numbers them from IFC onward. The specifics differ. The pattern does not: each stage has its own audience, and a change missed at one stage costs more at the next.

How deltas are found today

Three methods are in common use, and most teams run all three.

Clouds and triangles. The drafter clouds the changed area, tags it with a triangle carrying the revision number, and adds a line to the revision block. It is a good convention and a fragile one. On many projects, clouds are cleared at the next revision, so a sheet shows only its latest changes. Small edits, especially late ones, get made without a cloud. A cloud around half a sheet marked "revised per client comments" says that something changed, not what. And a change on one sheet often needs a matching change on the continuation sheet, which may never be clouded at all.

PDF overlays. Lay the old sheet over the new one and color the differences. Overlays catch unclouded changes, which is their real value. But they compare pixels, not engineering: a re-plotted title block or a shifted text label lights up as brightly as a new control valve. Scans rarely align cleanly. Overlays work one sheet pair at a time, so they lose the thread when content moves between sheets. And the output is a picture of difference, not a list of changes anyone can price, track or assign.

Checking by hand. An engineer lays two revisions side by side and works through them with a highlighter. On critical documents this is still the standard. It is also slow, and it depends on someone who has other work.

A revision cloud is the drafter's note about what changed. It is not a promise that nothing else did.

What a structured diff is

A structured diff compares what two revisions mean rather than what they look like. Each revision is read into the same typed model: equipment; lines with their size, spec and service; valves and instruments; the connections between them; notes and quantities. The two models are compared item by item, and the result is a list of changes, each one typed, located and checkable:

• What changed. Added, removed or modified, with the attribute that changed and its old and new values.
• Where. The sheet and region in both revisions, before and after side by side.
• Whether it was clouded. A change outside any cloud is flagged, because it is the one most likely to be missed.
• What it touches. A line that changes size on one sheet is followed onto its continuation sheets, so the cross-sheet consequence shows up in the same review.

An illustrative example. A cooling water P&ID moves from its review issue to IFC. The diff reports five changes: a line upsized from 6 to 8 inch, a new low-point drain, an instrument renumbered after a loop was split, a spec break moved two valves downstream, and a new tie-in on the continuation sheet. Four sit inside clouds. The spec break does not, and it is the change most likely to reach the fabrication shop unnoticed, with the wrong material class on the segment in between.

Each change can then be verified the way a tag is: an engineer confirms or corrects it, and the confirmation is logged. The engineer reviews changes, not sheets, for reasons we set out in why we verify every tag. The same comparison runs on isometrics and line lists, so the material take-off delta comes out of the same review.

From diff to change notice, variation and MOC

A verified list of changes is useful on its own. It becomes valuable when it feeds the processes that decide who pays for a change and whether it is safe.

Change notices

Most EPC contractors run an internal trend or change notice process that assesses every design change for cost and schedule. A structured diff gives each notice its starting point: the list of changes and the quantity deltas they cause, instead of an engineer's summary from memory.

Variation claims

On a lump-sum EPC contract, the contractor generally carries the cost of its own design development but not of changes the owner directs, and most variation disputes turn on which of the two a change was. A diff cannot settle that alone. It gives the commercial team the evidence: what changed, in which issue, on what date, in response to which comment, technical query or instruction, and what it did to quantities. Many contracts also set a notice period for claims, after which a change can be time-barred, so finding it within days matters.

The owner's management of change

On brownfield work inside an operating facility, changes to the process design run through the owner's management of change procedure. In the United States, facilities covered by OSHA's Process Safety Management standard, 29 CFR 1910.119, must manage changes through written procedures and keep process safety information, including P&IDs, up to date. A HAZOP is carried out on a specific revision. A structured diff between that revision and IFC is the exact list of what changed after the hazard review, which is what the MOC reviewers and the pre-startup safety review need.

Why the register should outlive the project

At handover, the owner receives as-built drawings and turnover packages: equipment data, test records, certificates. What usually stays behind is the revision history, archived with the contractor's document control system when the project closes. The owner gets the final state of every drawing and very little of how it got there.

That history is what operations needs later. An MOC on the new unit starts by asking why a valve is where it is. A PHA revalidation, which PSM requires at least every five years, asks which changes were made after the original hazard review and how each was assessed. The next revamp starts from a baseline, which is far easier to hand over than to rebuild from scans.

The comparison that matters most is the last one, IFC against as-built. It shows the field changes: reroutes and substitutions made during construction that were never issued as a formal revision. Captured at handover, it means operations starts with process safety information that matches the plant, rather than inheriting a gap that widens with every change.

So the register should be a handover deliverable in its own right: every issue of every document, every verified change between issues, and the reason for each, linked to the comment, query, variation or MOC behind it. It should arrive as structured data with the drawings, not as a transmittal log, and owners can write that into their handover requirements.

Habits that make it work

• Name the baseline for every comparison. Review issue against IFC, HAZOP revision against IFC, IFC against as-built, written into the document control procedure.
• Diff every issue, not just the large ones. Small late changes are the ones most likely to go unclouded.
• Send unclouded changes back to the originator. Fix the drawing, not just the downstream quantities.
• Record the trigger. Every change points to the comment, query, instruction or MOC that caused it.

The drawing is the summary, the register is the record

A drawing shows the current state of a design. The revision register explains how it got there, and on a plant that will run for decades, that explanation is worth nearly as much as the drawing. Build it as you go, verify it as you go, and hand it over with everything else.

For how we read and connect P&IDs, isometrics and line lists across sheets and revisions, see the platform and our energy and construction pages. For why these documents deserve this rigor, read The physical world runs on drawings.