Brownfield I/O Reconciliation. Keep, Remove, Replace.

There is always a wall set.

On most brownfield revamp projects, there is a set of P&IDs pinned or rolled out in the field office, annotated in pencil, sometimes in three different colours of ink, with date stamps from turnarounds that span fifteen years. There is also a controlled set in the document management system, last revised by an EPC contractor and issued at a revision that may or may not reflect what was actually installed during construction. And somewhere there is a vendor package from the last major modification, with its own P&ID sheets that cover a portion of the unit and disagree with the plant drawings at every boundary.

All three sets describe the same plant. None of them are fully right.

Reconciliation is the work of resolving those disagreements into a single list that can be handed to a controls engineer, a construction contractor, and a safety reviewer, and that each of them can trust for their purpose. The output is not a perfect as-built record of the plant. A full field inventory would be needed for that. The output is a keep, remove, replace register. A row per tag, a source citation per row, a verification status, and a defensible classification that feeds the management-of-change package.

Why brownfield is different

On a greenfield project, the I/O list is built from drawings that describe a plant that does not yet exist. Discrepancies between documents are engineering errors that can be corrected before anything is built. The I/O list is authoritative because there is no competing physical reality.

On a brownfield project, the I/O list is built from drawings that describe a plant that has been operating, often for decades, under a maintenance and operations team that makes practical decisions at the point of need. The I/O list produced from those drawings is a hypothesis about the current state of the plant, not a statement of it.

Several mechanisms drive the gap between drawings and field, and they compound over the life of a facility.

Turnaround scope that did not make it back to the master set. A shutdown happens. Instruments are replaced, some with different models or different ranges because that is what is available in the warehouse. The contractor updates their working set. The as-built redlines go to document control. The master P&IDs may not be updated for months, or at all if the turnaround contractor's package was accepted without a drawing update requirement.

Emergency field changes. A transmitter fails at night. Operations replaces it with a unit from stock that has a different range. Nobody opens a drawing during an emergency callout, and nobody opens one the next morning either. The drawing still shows the original range. The DCS has been reconfigured to the new range, or it has not, depending on who in the control room handled it.

Scope changes during the last construction project. The design shows PT-101 on the discharge header. The fitter put it on the suction side because the nozzle position was crowded. The deviation was noted in the construction punch list. The punch list was closed. The drawing was not updated.

Control system migrations that created parallel naming. Part of the plant was migrated from an older system to a newer one. The migrated loops got new tag numbers in the DCS. The P&IDs still show the original tags, or show both, or show the new tags inconsistently across drawing sheets. An engineer reading the P&ID and an engineer reading the DCS database are looking at the same physical instrument with different names.

The practical result is that the control system database contains tags that the current P&IDs do not show, and the current P&IDs show tags that are not in the control system and may not be in the field. Both conditions need to be resolved before the revamp scope is set.

For a longer treatment of how documentation drifts in operation, see MOC and P&ID Documentation: Why I/O Lists Drift.

The three sources and how to rank them

Three sources carry information about what instruments currently exist. The controlled P&IDs, the control system database, or legacy I/O list, and a physical walkdown. Each has a different relationship with ground truth.

The latest controlled P&ID revision is the nominal paper authority. It has been through a review and approval cycle. It carries a revision number and a date. It is the document that an engineering review references. Its limitation is that controlled revisions lag field reality. The latest controlled revision governs on paper, but it governs in the drawing office, not in the field.

The control system database or legacy I/O list represents what is currently wired to the control system. It may include instruments that were added under minor modifications that did not require a P&ID revision, or instruments that were rewired during maintenance. It does not include instruments that exist in the field but were never connected to the control system, local gauges, local indicators. Its limitation is that it reflects wiring, not physical condition. A channel can be wired to a dead transmitter, an abandoned tapping point, or a wall termination that goes nowhere.

A physical walkdown is the only source that reflects the current physical state directly. It is also the slowest and most expensive source. On a large unit with hundreds of instruments, a complete walkdown of every tag is a significant resource commitment. The practical approach is to walk selectively. The instruments where the first two sources disagree, and the instruments where the consequence of being wrong is high.

**Precedence rule. ** On paper, the latest controlled revision governs. If the DCS database contradicts the latest controlled revision, that is a flag for investigation, not a reason to override the drawing. The walkdown resolves the conflict. Document the precedence rule and its exceptions. There will be cases where a DCS channel has live, real signal data for a tag that does not appear on any controlled drawing, and that tag needs to enter the register.

Reconciling revisions

The most common conflict is the same tag appearing on two drawing revisions with different values. Usually different ranges, sometimes different signal routing, occasionally a different signal class.

Consider a level transmitter, LT-2201, that appears on revision B of drawing PID-022 with a range of 0-3000 mm and on revision D of the same drawing with a range of 0-2000 mm. Revision D is the latest controlled revision. It governs on paper. But the DCS database shows an engineering range of 0-3000 mm, matching revision B.

This is not unusual. During a prior revamp, the process engineer may have changed the operating level range and updated the drawing without updating the control system configuration, or vice versa. Or the drawing was updated speculatively and the instrument was never actually replaced in the field.

The desk cannot resolve this. What the desk can do is record the conflict precisely. Source drawing PID-022, revision D, range 0-2000 mm. DCS database, channel LT-2201, engineering range 0-3000 mm. Conflict noted. Walkdown required. The walkdown then captures the nameplate range on the installed transmitter and determines which value reflects the physical instrument.

The resolution follows. If the nameplate confirms 0-2000 mm, the DCS has a configuration error and a control system change order is required. If the nameplate confirms 0-3000 mm, revision D of the drawing has an error, and the drawing needs to be corrected as part of the revamp documentation package. Either way the I/O list row carries the physically confirmed value once the walkdown is complete.

The same logic applies to signal class conflicts. If TI-1102 appears as an AI on the latest drawing and as a DI in the DCS, which happens when a temperature element that was once a thermocouple was replaced with a local indicator and a discrete high-temperature switch without a corresponding drawing update, the conflict is flagged and walked.

For context on extracting instrument data from old drawing sets where these conflicts are embedded in the source documents, see Scanned P&IDs vs CAD Exports: What to Expect.

The keep, remove, replace classification

Once the sources have been cross-referenced and conflicts flagged, every tag in the register gets one of three classifications.

Keep. The tag is on the latest controlled P&ID. The instrument is present in the field. The specification has not changed. The device is to remain as installed and is within the revamp boundary only for documentation purposes. No construction work is required for this tag. The I/O channel carries through. Verification status. Confirmed by paper sources if the sources agree. Confirmed by walkdown if there was any conflict.

Remove. The tag is not on the latest controlled P&ID, is not in the field, or falls within a section of the plant that is being demolished or decommissioned. The channel is to be decommissioned. Walk every remove candidate before finalising the classification. The cost of walking a tag that turns out to be live is small relative to the cost of a field change order when the construction crew terminates an active signal. Verification status. Walkdown required before the classification is frozen.

Replace. The device exists in the field but is being changed out under the revamp. This covers instrument upgrades, range changes, and changes driven by process modifications. A replace row records the old tag, the new tag if it is changing, often the tag number is preserved, but not always, the old signal class, the new signal class, the reason for replacement, and whether the change requires a new DCS channel or reprograms an existing one. A common replace scenario is a pressure transmitter PT-101 being upgraded from a standard BPCS transmitter to a SIS-rated device with a new tag under the SIS rack assignment. The old device is removed, the new device occupies a new physical channel, and the MOC covers both the removal and the addition.

The register is a living document during the engineering phase. Tags shift classification as walkdown results come in and as the revamp scope is refined. The register is frozen when the MOC package goes to review.

The walkdown

The purpose of the walkdown is not to verify every tag. It is to verify the tags where the paper sources disagree and the tags where the consequence of getting it wrong is high.

Walk the following.

• Every tag flagged as a conflict between the latest controlled drawing and the control system database.
• Every tag classified as remove, before the classification is frozen.
• Every tag that feeds a safety instrumented function, regardless of apparent agreement between paper sources. A SIS transmitter that is misclassified on the I/O list is a safety management issue, not an engineering paperwork issue.
• Every tag on a section of plant that has not been formally walked in more than a defined period. The engineering manager should set this threshold. Five years of no formal walkdown is a reasonable trigger for a full-section check rather than spot verification.

On the walkdown, capture the following for each tag.

• Tag is physically present or absent at the P&ID location.
• Model number and serial number from the nameplate.
• Nameplate range, for transmitters or nameplate rating, for valves.
• Physical condition. Instrument appears operational, appears abandoned, or is missing entirely.
• Whether the tag is included in a panel or local enclosure that is not shown on the current drawing.

Record walkdown findings in the register with a date and the initials of the person who walked the instrument. This is the verification record. If a finding contradicts the paper sources, the discrepancy and its resolution are noted in the register before the classification is assigned.

One practical point. Walkdowns go faster when the engineer doing the walk has the register open on a tablet rather than working from paper. The register can be updated in the field with the finding, rather than transcribed from field notes later. Transcription introduces errors. It also introduces delays, which matter when the walkdown results are on the critical path for the MOC package.

The register becomes the MOC basis

The keep, remove, replace register is not a standalone document. It is the as-found baseline that the management-of-change package requires before the revamp scope can be formally approved.

An MOC for a revamp must establish what the plant looks like before any work is done. Without that baseline, it is not possible to evaluate the safety impact of the changes, because the impact of a change depends on what is being changed from. A regulator or auditor reviewing the MOC package will expect to see the as-found state documented, the changes listed, and the post-change state described. The register provides the first two.

The register also becomes the redline basis for updating the controlled P&IDs after the revamp is complete. Every replace row and every remove row describes a change that needs to be reflected in the drawings. The revamp contractor's as-built record should map back to the register, not to a separate set of field notes.

For the broader topic of how the MOC package is structured and how the I/O list fits into it, see MOC and P&ID Documentation: Why I/O Lists Drift.

A worked walkthrough

To make the classification work concrete, consider a small section of a gas-processing unit covering three instruments.

LT-2201. On the drawing, not in the field. The latest controlled revision of PID-022 shows LT-2201 as an AI, 0-2000 mm, on vessel V-201. The DCS database has no channel assigned to LT-2201. The walkdown confirms no transmitter is installed at the nozzle shown on the drawing. The nozzle has a blind flange. This tag is classified remove. The remove row records the drawing reference, PID-022, Rev D as the source, the DCS absence as corroboration, and the walkdown date as the verification. The MOC will cover the formal decommissioning of the nozzle if it is not being reused.

TI-1102. Different range in the DCS than on the drawing. The latest controlled revision of PID-034 shows TI-1102 as an AI with a range of 0-200 degrees. The DCS database shows TI-1102 on an AI channel with an engineering range of 0-400 degrees. The walkdown finds a thermocouple transmitter at the correct location. The nameplate shows a measurement range of 0-400 degrees. The DCS is right. The drawing was not updated when the transmitter was replaced during a previous turnaround. This tag is classified keep. The I/O list row carries the DCS and nameplate range of 0-400 degrees. A drawing correction is logged as a work item for the revamp documentation package.

PT-101. Being replaced with a SIS-rated device. The revamp process hazard analysis has identified a high-pressure scenario on the discharge of pump P-301 that requires an SIS interlock. The existing PT-101 is a standard BPCS transmitter, 4-20 mA, AI, wired to the BPCS PLC rack. The new design requires a SIS-rated transmitter at the same location, assigned to a new tag under the SIS I/O list. The old PT-101 is being removed and the new SIS transmitter will carry a new tag number. This tag is classified replace. Old tag PT-101, new tag to be assigned by the SIS design engineer. The reason for replacement is recorded. The replace row generates two downstream actions. A remove entry in the BPCS I/O list for the old channel, and an add entry in the SIS I/O list for the new channel. Both are MOC scope items.

These three tags, resolved through the reconciliation pass, represent the three distinct decisions the register must support. A channel coming out, a channel staying with a corrected value, and a channel being removed and replaced under new scope.

What goes wrong

Several failure modes recur across brownfield reconciliation projects, and most of them are procedural rather than technical.

Trusting the controlled drawing over the field. The controlled P&ID is the nominal paper authority, but it is not the field. Engineers who work primarily from drawings and do not walk the plant carry the risk of building an I/O list that reflects the document archive, not the installed plant. The reconciliation is worth doing precisely because the drawing is not reliable. Using it as if it were defeats the purpose.

Not recording source-drawing and source-revision for each tag. A reconciliation register without source citations cannot be audited. On a revamp project a tag classification will be questioned. By the MOC reviewer, by the commissioning team, by the safety reviewer. The only way to defend the classification is to show the sources it was derived from and the walkdown record that resolved any conflict. A register with a classification column but no source column is an opinion, not a record.

Walking every tag. A full-site physical inventory of every instrument on a large unit takes weeks of engineering time and delays the MOC package. The walkdown should be targeted. Walk the conflicts, walk the removes, walk the safety-critical loops. Accept paper sources for tags where the sources agree and the consequence of error is recoverable.

Walking no tags. The opposite failure is accepting the controlled drawing as accurate without any physical verification. This produces a reconciliation that looks complete but is built on the assumption that the drawings are right. They are not. The minimum is to walk every remove candidate and every SIS-feeding tag.

The reconciliation done in someone's head. On smaller projects it is tempting to skip the register and carry the reconciliation in memory or in a running conversation between engineers. This works until the MOC review, where the reviewer asks for documentation of the as-found basis and there is none. The register must exist as a document, with one row per tag and a revision date when it is frozen for the MOC submission.

The MOC package referencing a list that was never frozen. The register is a working document during engineering. It changes as walkdown results come in. If the MOC package references the register by name without a specific revision or date, and the register continues to be edited after the MOC is submitted, the MOC baseline is undefined. Freeze the register before the MOC package goes to review. Version it, lock the file, or issue it as a controlled document. Any changes after that point require a revision to the MOC.

Getting the instrument list out of the drawings

The reconciliation starts with having the instrument list from the latest controlled drawings in a form that can be cross-referenced against the DCS database. On a project with dozens of P&ID sheets and hundreds of tags, extracting that list by hand is time-consuming and error-prone. Missed tags on a manual extraction become missed rows in the register.

Tagsight reads P&IDs, including older scanned drawings with hand annotations, and produces a tagged list with signal class, loop number, and drawing reference per instrument. That list can serve as the paper-source column of the reconciliation register. If the drawing set is mixed, some sheets as vector PDFs, some as scanned images, extraction handles both, with the scanned sheets flagged for manual verification of low-confidence tags. See extracting instrument data from brownfield drawings for how the extraction process handles legacy drawing formats.

For the case where the drawing set has gone through multiple scanner generations and annotation layers, the additional context in Reading Legacy 1980s P&IDs is relevant to setting expectations on what the extraction can and cannot resolve automatically.

And if the revamp scope involves migrating from an older control system and the DCS database is the primary source of current channel assignments, DCS Migration: Extracting Current Scope From P&IDs covers how to use the P&ID extraction output alongside the existing DCS tag list to build the scope of the migration.

The register is not the same as an accurate set of drawings. It is a defensible record of what is known, what was verified, and what decisions were made from that information. That distinction matters when the MOC is reviewed, when the commissioning team inherits the scope, and when the next revamp engineer opens the drawing set five years from now and finds it actually matches the plant.