TL;DR

  • Drawings Reflect Design Intent, Not Installed Reality: Equipment records extracted from engineering drawings show intended tag names and ratings, but they cannot confirm actual field swaps, serial numbers, or procurement updates.
  • Separate Document Data from Field Verification: Every record entry should cite its source drawing number and revision letter, maintaining a clear distinction between drawing-derived data and field-confirmed status.
  • Preserve Exact Tag Names and Explicitly Flag Uncertainty: Record tag names precisely as printed on drawings while logging operational designations separately, and explicitly mark ambiguous or unreadable values instead of making assumptions.

# # #

Before a data center is handed over, someone has to produce the equipment record that operations will live with: every switchboard, UPS module, generator, chiller, pump, CRAH unit and valve, with a tag, a location and a source. Most of that record starts in the drawings. One-line diagrams, mechanical piping schematics and cooling P&IDs name the equipment long before it is installed. Errors can enter the record when information is copied out of those drawings into a list.

A drawing can establish less than people assume. A one-line diagram shows that a breaker exists, what it feeds and what its tag is. It often shows a rating. It does not show the serial number, the firmware version, or whether the unit installed is the unit that was drawn. A cooling schematic shows a chilled water pump, its tag and the loop it serves. It does not show that the pump was swapped for a different model during procurement. A list built from drawings reflects what those documents record. It does not, by itself, verify what is installed. Treating it as a verified record of installed equipment is an easy mistake to make because the two can look identical in a spreadsheet.

The practical fix is to keep document-derived information and field verification distinct. Every row extracted from the documents carries the drawing number and the revision it was read from. A second step, done on the floor or from commissioning records, confirms each row against the installed equipment and adds what only the field can know. When the two disagree, the record should show the disagreement, with both values, until someone resolves it. A field marked “not shown on the drawing” is more useful to a facilities team than a plausible value nobody can trace.

Revisions are where document-derived lists drift. Power and cooling drawings change through design, construction and commissioning, and a list typed from revision B is quietly wrong by revision E. The tag of a renumbered panel changes on the drawing and not in the list. A generator added for a later phase appears on the one-line and never reaches the asset register. The habit that prevents this is simple and tedious: every row keeps the revision it came from, and each new drawing issue is compared with the last one, tag by tag, so that additions, deletions and renumbering are found as a set and not discovered one at a time after handover.

Tags deserve their own care. The same piece of equipment is often named three ways: the designer’s tag on the drawing, the manufacturer’s designation on the nameplate, and the name the operations team wants in the maintenance system. Problems start when a list silently translates one into another. Keep the tag exactly as the drawing prints it, hyphens and all, and add the other names beside it as separate fields. Anyone who later has to trace a work order back to a drawing will be able to.

Uncertainty should be written down, not smoothed over. Scanned drawings have characters that cannot be read with confidence. A tag may be partly hidden by a revision cloud, or a rating may be legible on one sheet and different on another. The person preparing the list will be tempted to pick the likely answer and move on. A better record marks the row as unconfirmed, says why, and points at the sheet. The commissioning team can then prioritize flagged rows while carrying out the required verification of the wider record.

A short checklist covers most of it. Every row names its source drawing and revision. Tags are recorded as printed. Document-derived information and field verification status are distinguishable. Unreadable or conflicting values are flagged. Each new drawing issue is compared against the list before the list is reissued.

The principle is straightforward. Every line in an equipment record should show where it came from and whether it has been verified. Data centers are built quickly and handed over on a date, and that record is one of the few things from the project that the operations team will still be using ten years later.

# # #

About the Author

Muaawia Jannat is the founder and CEO of Tagsight Technologies Inc., a Calgary-based company developing engineering software for instrumentation and controls teams. His work focuses on turning engineering drawings into structured equipment and instrument records that teams can review, trace to their source and use in downstream workflows.