
A Master Tag Register (MTR) is the authoritative, governed register of tagged items within an industrial facility — including equipment, instruments, pipelines, valves, electrical assets and other identifiable objects. Each record is associated with a unique tag number that allows the same physical item to be identified consistently across engineering, procurement, commissioning, operations and maintenance.
The MTR is therefore more than an equipment list or spreadsheet. It provides the common identity layer connecting physical assets with their engineering data, documents, supplier information and downstream operational systems.
Where individual engineering disciplines may maintain their own lists, the Master Tag Register provides a cross-discipline reference against which tag identities and associated information can be reconciled.
A tag number is a unique identifier assigned to an equipment item, instrument, line or other tagged object within a facility.
The tag provides the connection between the physical item and the information describing it. Depending on the asset and project, this can include:
For example, the same pump may appear on a P&ID, equipment list, supplier datasheet, commissioning record and EAM system. A consistent tag number allows all of those records to be associated with the same physical pump.
This is why tag management is not simply a naming exercise. The tag is one of the primary keys connecting industrial asset information.
The exact attributes vary between projects and owner-operators, but a Master Tag Register commonly contains:
The required attributes should ideally be defined as part of the project's information requirements before data begins arriving from engineering contractors and suppliers.
A mature MTR therefore governs not only which tags exist, but also their attributes, relationships, status and history.
Industrial facilities normally establish a tag numbering convention defining how identifiers are created, structured and controlled.
Depending on the organisation, industry and facility, a tag may encode information such as equipment type, plant area, system, function and sequence.
Industry standards can support consistent equipment classification and information structures. For example, ISO 14224 provides equipment taxonomy and requirements for reliability and maintenance data in the petroleum, petrochemical and natural gas industries. Power-generation organisations may use identification systems such as KKS.
The actual tag numbering convention, however, is frequently owner- or project-specific.
The critical requirement is consistency: every identifier should be unique and governed so that different disciplines, contractors and systems do not create competing identities for the same physical item.
These terms are related but answer different questions.
Equipment list: An engineering deliverable containing equipment within a defined project or discipline scope, usually with design and process attributes.
Asset register: The operational record of assets used by an owner-operator, often maintained within an EAM or CMMS.
Master Tag Register: The governed, cross-discipline register of tag identities and associated master attributes used to reconcile information across engineering and operational systems.
The distinction becomes especially important at handover.
The engineering equipment list describes equipment within the project scope. The operational asset register needs the information required to operate and maintain installed assets. The MTR provides the controlled identity layer connecting those environments.
A Master Tag Register is not static. Tags are created and changed as a project moves from engineering through construction and into operations.
A typical lifecycle includes:
Creation — A tag is proposed and checked against the applicable numbering convention and existing register to ensure uniqueness.
Approval and issue — The tag becomes an approved identifier available to engineering disciplines, contractors and suppliers.
Enrichment — Attributes, supplier data, documents and relationships are progressively associated with the tag as engineering and procurement develop.
Modification — Changes to descriptions, classifications, relationships or controlled attributes are recorded with appropriate approval and traceability.
Construction and commissioning — Tag information is reconciled against installed equipment and commissioning records.
Handover — Validated tag records and required attributes are transferred into the owner-operator's operational information environment.
Operation — The identifier continues to connect maintenance, inspection, documentation and asset information.
Retirement — When equipment is permanently removed, its historical identity should normally be retained rather than simply deleted or reused.
Effective change control is therefore fundamental to MTR governance.
The problem is rarely that a project has no tag list.
The problem is that it has multiple versions of the truth.
Common causes include:
These discrepancies accumulate throughout project execution.
If reconciliation is postponed until close-out, an owner-operator can receive documents and datasets that are individually valid but cannot be reliably connected to the physical assets they describe.
That is fundamentally an information relationship problem, not simply a document problem.
A significant amount of equipment information is created outside the owner organisation by manufacturers, vendors, EPCs and subcontractors.
Effective Supplier Data Management therefore depends heavily on consistent tag identities.
Supplier datasheets, certificates, manuals, drawings and equipment attributes should be associated with the appropriate tags as information is submitted — rather than trying to reconstruct those relationships at project close-out.
Done correctly, this creates traceability across:
tag → equipment → supplier → document → revision
and allows missing or conflicting information to be identified while the responsible project participants are still available to resolve it.
The relationship between tags and documents is another critical part of MTR management.
A P&ID may contain hundreds of tags. One equipment tag may in turn appear across multiple datasheets, drawings, certificates, manuals, inspection records and supplier documents.
Maintaining these relationships allows users to navigate from an asset to the information describing it — and from an engineering document back to the relevant assets.
This becomes particularly important when preparing a document handover package.
A successful handover is not simply about delivering all required documents. Operations must also be able to determine which information belongs to which asset.
Competitor solutions increasingly address parts of this problem through tag extraction and validation against an MTR, demonstrating how important the tag-document relationship has become in engineering information management.
Handover is where weaknesses in tag governance become highly visible.
Before information is transferred into operations, the MTR should be reconciled against the final project scope and the receiving organisation's information requirements.
Typical checks include:
Hexagon's MTR workflow similarly connects tag allocation, vendor technical information, validation and generation of the register for handover and asset-management purposes.
When these controls happen continuously during project execution, handover becomes a transfer of validated information.
When they happen for the first time at close-out, handover becomes a data-reconciliation exercise.
The MTR is an important upstream source for Enterprise Asset Management (EAM) and CMMS environments.
Operational systems need reliable equipment identities and structured attributes before maintenance processes can work effectively.
A validated MTR can provide the foundation for:
The EAM or CMMS can manage assets throughout operations, but it cannot automatically repair equipment identities and relationships that were incomplete or inconsistent when information arrived from the project.
Operational asset data quality therefore starts upstream.
A digital twin requires a reliable connection between its digital objects and the physical facility.
The Master Tag Register provides an important part of this connection by establishing consistent identities for the objects represented digitally.
Those identifiers can connect engineering information, documentation, operational data, maintenance history and other contextual information to the appropriate physical assets.
The same principle applies to a digital backbone: systems can exchange asset information effectively only when they agree on what each object is and how it is identified.
A well-managed MTR can provide:
The important distinction is that the value does not come from having a spreadsheet called Master Tag Register. It comes from governing the identities and relationships throughout the lifecycle.
Sharecat provides a central environment for consolidating tags, equipment and associated information from multiple sources.
Instead of treating the MTR as an isolated spreadsheet, Sharecat connects tag records with equipment, documents, purchase orders, suppliers, responsibilities and other related information. It can also extract tag information from documents and validate it against governed data, helping build the register as project information develops.
This creates a connected information structure in which users can work across:
tags ↔ equipment ↔ attributes ↔ documents ↔ suppliers ↔ project relationships
Tag numbering can be controlled, duplicate identities identified, information requirements applied to different equipment types, and completeness monitored as information is delivered. Sharecat's current MTR solution specifically supports tag synchronisation, document data extraction, completeness checking and automatic creation of relationships and hierarchies.
The result is not simply a list of tags for handover. It is a governed information structure that can be maintained through project execution and prepared for downstream operational use.
This is also where Sharecat's positioning differs from narrower approaches focused primarily on tag-register generation, tag extraction or data normalization: the MTR becomes part of the wider industrial document-and-data environment.
A Master Tag Register (MTR) is the authoritative, governed register of tagged items within an industrial facility. It maintains consistent tag identities and associated information across engineering, procurement, commissioning, operations and maintenance.
The MTR governs tag identities and associated master information across engineering and project systems. An asset register is generally the operational record of assets used for maintenance and asset management. Information from the project MTR can therefore provide an important input to the operational asset register.
An equipment list is typically an engineering deliverable containing equipment and design information within a particular scope. The MTR is a governed cross-discipline register intended to maintain consistent tag identities and relationships across multiple sources and systems.
An MTR commonly contains tag number, description, object or equipment class, discipline, system, location, service, lifecycle status and relevant equipment attributes. It may also maintain relationships to engineering documents, suppliers, parent assets and downstream systems.
The MTR helps establish which tagged assets exist and connects those identities to the structured data and documentation required by operations. A validated register reduces the amount of reconciliation required before information can be loaded into EAM, CMMS and other operational systems.
The governing principles, numbering conventions and required information should be defined early in the project, ideally before large volumes of engineering and supplier information are created. Correcting inconsistent identifiers becomes progressively more difficult as more documents and systems begin referencing them.
Tag lifecycle management is the controlled process for creating, approving, modifying, using and eventually retiring tag identifiers. Changes should remain traceable so that related engineering and operational information continues to reference the correct physical asset.
A spreadsheet can hold a tag list, particularly on small projects, but becomes increasingly difficult to govern as the number of tags, contributors, attributes, documents and relationships increases. A governed MTR adds validation, relationships, permissions, workflows and change traceability that a standalone spreadsheet does not inherently provide.