Book a demo
Login
Ask any experienced information manager what goes wrong on a capital project and the answer rarely starts with late drawings or difficult contractors. It starts with the tag register — or more precisely, with nobody owning it properly.
On a large oil and gas development or chemicals plant there can be 50,000 to 200,000 tagged items: pumps, compressors, valves, instruments, vessels, motors, pressure transmitters, cable trays. Each needs a unique, unambiguous identifier. Each needs to connect its engineering documents to procurement records, inspection certificates, vendor manuals, and eventually a maintenance plan in the CMMS. That identifier is the tag number. The authoritative governed list of all those tag numbers — the Master Tag Register — is the most important piece of data infrastructure on the project.
A Master Tag Register (MTR) is the definitive, centrally governed list of every tagged equipment item, instrument, pipeline segment, and functional location in a project or operating facility. Each entry carries the tag number, equipment class, service description, plant location in the hierarchy, and the current status of the tag — active, on-hold, superseded, or deleted.
Beyond basic identification, each tag links to the documents and data attributes that define it: the P&ID it appears on, the datasheet specifying its technical parameters, loop diagrams or single-line drawings, the functional location in the CMMS hierarchy, and the commissioning system it belongs to for turnover purposes. For the technical definition of master tag register structure, tagging conventions, and data model, see our Master Tag Register glossary entry. A well-managed MTR is not a static spreadsheet — it is a live, governed database that reflects the current engineering state of the plant.
Equipment tag numbers are the universal key connecting every layer of a capital project's information architecture. They link engineering to procurement, procurement to vendor documentation, vendor documentation to inspection records, and inspection records to commissioning certificates. Break this chain — allow duplicate tags, inconsistent formats, or divergence between engineering and procurement systems — and every downstream process that relies on those linkages becomes unreliable.
The consequences are predictable. Procurement teams order equipment against outdated specifications because the purchase order tag does not match the current engineering revision. Vendors submit documentation against their own internal product codes instead of project tag numbers, making automatic linkage impossible. Completions teams cannot verify document coverage per tag because the completions system uses a different version of the register than the document management system. At handover, CMMS population requires months of manual reconciliation — matching equipment records from four or five source systems that each started from a slightly different list.
These are not rare failures. They are the default outcome on projects where the tag register is managed informally — in separate discipline spreadsheets, in systems that do not validate against a single master, or across contractor silos that are never synchronized with the owner-operator's requirements.
The tag register is not a handover artifact — it is established in FEED and governs every subsequent phase.
In FEED and early engineering, the tag register is developed as P&IDs are produced. The tagging convention — the rules defining tag number structure for each equipment class — must be agreed and documented before any discipline begins producing tagged documents. Inconsistencies introduced in FEED are expensive to correct in detail engineering and nearly impossible to fix at handover without data cleansing effort.
In detailed engineering, the register grows as instruments are added, piping is tagged, and electrical items get functional locations. Every tag created in any engineering tool — the P&ID authoring tool, the instrument database, the electrical design system — must be validated against the master register before acceptance. Tags not in the MTR should not appear on issued drawings; tags in the MTR should not be missing from drawings that claim to show complete scope.
In procurement, the MTR drives purchasing. Each purchase order references specific tags, linking the commercial record to the physical item being procured. The SDRL (Supplier Document Requirements List) for each order is defined by what documents must be delivered against each tag. When the procurement system works from a different tag list than the engineering system, the purchase order to engineering document linkage becomes unreliable. See our guide to engineering document management in oil and gas for detail on how the SDRL, transmittal processes, and vendor documentation management work alongside the tag register.
In construction and commissioning, the MTR is the foundation of the completions process. Mechanical completion is verified tag by tag: for each tagged item in scope, has it been installed, inspected, and documented? Punch lists are organized by tag. System completion is tracked by grouping tags into commissioning systems. All of this depends on a tag register that accurately reflects what is installed — not what was originally designed two years earlier.
At handover, the MTR and all its associated links — documents, technical attributes, inspection records, commissioning certificates — transfer to the owner-operator and become the foundation of the operational asset record. The CMMS is populated with equipment records derived from the MTR. Maintenance plans are attached to tag numbers. The inspection history accumulated during construction carries forward under the same identifiers that will be used throughout the asset's life.
Tag register failures follow consistent patterns that experienced project teams recognize.
Duplicate tags occur when different disciplines or different contractors create their own tag for the same physical item without a governed master preventing it. A pump with two different tag numbers in the engineering database has two maintenance records in the CMMS, two separate document sets, and two histories — none of which is complete.
Cross-system inconsistency occurs when the same equipment is known by different identifiers in the P&ID tool, the instrument database, the procurement system, and the document management system. Each system becomes an island, connected to others by manual lookup rather than through a shared validated identifier.
Stale tags occur when the register is not maintained as design changes occur. Equipment deleted from scope continues to appear in procurement and completions systems. Equipment added in a late engineering change is missing from the register that commissioning teams are working from. The gap between the register and reality grows silently throughout the project until reconciliation at handover reveals how large it has become.
Format non-compliance occurs when the tagging convention is not enforced consistently. A tag that does not follow the defined format cannot be parsed by downstream systems to extract equipment class, plant area, or service — making it impossible to use as a reliable machine-readable identifier.
At handover, the master tag register becomes the owner-operator's permanent asset identity record — the foundation on which CMMS maintenance plans, inspection programs, spare parts management, and increasingly, predictive maintenance AI are built.
A CMMS populated from a complete, accurate, consistently structured MTR has a reliable equipment hierarchy, complete technical attributes, and a document set searchable by tag number. A CMMS populated from a fragmented, inconsistent, partially complete register has split maintenance histories, missing attributes, documents that cannot be found by tag search, and an equipment hierarchy that does not match the physical plant.
For organizations investing in predictive maintenance and AI-assisted asset management, MTR quality at handover is the primary determinant of AI model effectiveness. Predictive models depend on complete equipment attribute data and structured maintenance history linked to the correct identifiers. If those linkages are broken at the MTR level, no downstream analytics layer can compensate.
Sharecat is designed around the master tag register as the central object in project and asset data management. Every document, every technical attribute, every inspection certificate, and every commissioning record in Sharecat is linked to a validated, governed tag — not stored as a loose file that references a tag number in free text, but explicitly associated with a controlled tag record.
The Sharecat tag register enforces the project's tagging convention at the point of entry: tags that do not conform to the defined format are rejected before they enter the system. Duplicates are prevented by validation against the existing register. Changes to the register — adding, modifying, or retiring tags — follow a governed workflow with approval routing and a complete audit trail.
Supplier and EPC document submissions are validated against the live tag register: documentation cannot be accepted if it references tag numbers not in the register, eliminating the orphaned documentation problem that creates gaps at handover. Completeness can be measured at tag level at any point in the project: for each tag in scope, which required documents are present, which data attributes are populated, and which gaps remain before the tag is ready for turnover.
At handover, Sharecat's tag-linked data environment integrates with the owner-operator's CMMS — SAP PM, IBM Maximo, IFS, and others — carrying document linkages and equipment attributes in a governed format that makes the operational asset record immediately usable. On the BP Tangguh LNG Expansion, Sharecat managed 170,812 tagged equipment items and 7,650,321 data attributes from 391 suppliers across the full project lifecycle.
For teams running Advanced Work Packaging programmes, the governed tag register Sharecat provides is also the data foundation that makes AWP constraint checks on engineering completeness reliable and IWP scope accurate through engineering changes. See our article on why Advanced Work Packaging depends on engineering data governance for detail on how the two work together.
A P&ID (Piping and Instrumentation Diagram) is a schematic showing how equipment and instrumentation are connected in a process system. Tag numbers appear as labels on each item. The Master Tag Register is the authoritative database governing those tag numbers — it validates what appears on P&IDs, maintains the governing record for each tag, and links each tag to its complete documentation, technical attributes, and procurement records. The P&ID is a drawing; the MTR is the master data record that governs it.
At the start of FEED, when the first P&IDs are being produced and the first equipment items are being identified. The tagging convention must be agreed before any engineering discipline produces tagged documents. Starting the MTR at FEED prevents the inconsistency and duplication that becomes expensive to correct in detail engineering and ensures procurement starts from the same governed list as engineering.
Each tag in the register becomes an equipment record in the CMMS, carrying its tag number, equipment class, description, technical attributes, plant location, and links to associated documents. A governed MTR with complete, accurately structured records enables automated or semi-automated CMMS population — reducing handover from months of manual data entry to a governed export process. Organizations managing the MTR informally in spreadsheets typically face weeks or months of CMMS data entry at handover; organizations with a governed digital MTR reduce this to days.
In a properly governed tag register, tags are not deleted — they are retired or superseded with a change record and audit trail. This preserves the history of what was designed, why it changed, and when. Downstream systems — procurement, completions, vendor documentation — are updated to reflect the tag's retired status, preventing ghost tags from continuing to generate workscopes for equipment that will never be installed. The change trail also supports engineering change management and contractual scope claims.
ISO
27001
Certified
