A tag register is the master list of every uniquely identified item on a project, such as equipment, instruments, valves, lines, cables and electrical components, with the attributes needed to design, build, inspect, commission and maintain it. In completions, it is the foundation everything else hangs off: each tag is assigned to a subsystem, each tag type generates the inspection and test records (ITRs) it needs, and each punch item and certificate traces back to tags. If an item is not in the tag register, as far as the completions system is concerned, it does not exist.
That is why an incomplete or out-of-date tag register is one of the quietest and most expensive problems on a project. The missing items do not show up on any progress report. They show up during commissioning, or after handover.
What is a tag register?
Engineering produces tags long before construction starts. Every pump on a P&ID, every transmitter in the instrument index, every cable in the cable schedule and every line in the line list carries a tag number. The tag register brings these together into one list, usually called the master tag register (MTR), with a consistent set of attributes for each.
Different teams use it for different things:
- Engineering uses it to control what has been designed and on which documents each tag appears.
- Procurement links tags to purchase orders and vendor data.
- Construction and completions use it to define the scope of inspection and testing for each subsystem.
- Commissioning uses it to plan tests and track system readiness.
- Operations and maintenance inherit it as the starting point for the asset register in the maintenance management system.
In some organisations the "tag register" and "equipment register" are the same thing; in others the equipment register only covers physical equipment while the tag register also includes lines, cables and functional tags such as control loops. The asset register used by operations may be a filtered and restructured version of either. Agree the terminology on your project so everyone means the same list.
Equipment tag register: required attributes
The exact fields depend on the project and the owner's information requirements, but a completions-ready tag register typically holds the following.
| Attribute | Purpose |
|---|---|
| Tag number | Unique identifier, following the project numbering procedure |
| Description | Plain-language name, e.g. "Cooling water pump A" |
| Discipline | Mechanical, piping, electrical, instrumentation, telecoms, HVAC, etc. |
| Tag type or class | Drives which ITRs apply (centrifugal pump, pressure transmitter, LV motor, MV cable) |
| System and subsystem | Commissioning scope the tag belongs to; exactly one subsystem per tag |
| Area / location | Plot area, module, building, level or room |
| Source documents | P&ID, single-line diagram, layout, datasheet, instrument index or cable schedule reference |
| Parent tag | For components that belong to a larger item (motor on a pump, instrument on a vessel) |
| Purchase order / vendor | Links to vendor documentation and spares |
| Status | Active, deleted, on hold, superseded |
| Construction contractor | Who installs it and therefore who completes its A-type ITRs |
Owners following a data standard such as CFIHOS will also specify classes and properties for each tag type, which makes the handover data far more useful to operations. It is much easier to capture these as the register is built than to retrofit them at handover.
Tag numbering conventions
Every project has a tag numbering procedure, often supplied by the owner and applied across all contractors. The formats differ, but most follow the same logic: a code for location or unit, a code for the type of item, and a sequence number, with optional suffixes for parallel or spare items.
Illustrative examples of the pattern (not a standard):
- Equipment:
20-P-1001A, where 20 is the unit, P is pump, 1001 the sequence and A the duty unit of a duty/standby pair. - Instruments:
20-PT-1043, following an ISA-style function code such as PT for pressure transmitter, with the loop number shared by related devices. - Lines:
6"-CW-20-1012-A1A, combining size, service, unit, sequence and piping class. - Cables: a cable number derived from the source and destination or from a sequence within the cable schedule.
Whatever the convention, the rules that matter for completions are the same:
- Every tag is unique across the project. Duplicates break the link between records and physical items.
- The format is validated. A register that accepts free-text tag numbers will end up with
P-1001A,P1001AandP-1001 Aas three different items. - Deleted tags are marked, not removed. If a tag is deleted from design after ITRs have been raised against it, you need to see that history.
- Physical tags match the register. Tag plates, cable markers and labels fitted on site must use exactly the same numbers. Mismatches are a steady source of punch items.
Linking tags to systems and ITRs
The tag register becomes a completions tool when each tag is linked to its subsystem and its inspection scope.
Assigning tags to subsystems
Systemisation defines the boundaries on the drawings; the tag register records the result. Each tag should be allocated to one subsystem, with boundary items such as tie-in valves or spectacle blinds allocated deliberately rather than by default. Our guide to systemisation in commissioning covers how to set those boundaries. A quick check that pays off: filter the register for tags with no subsystem. That list should be empty before construction starts producing ITRs.
Generating the ITR scope from tag types
Most completions systems map each tag type to a set of ITRs. A pressure transmitter might get an installation ITR (A-type) and a loop check (B-type); an LV motor might get installation, insulation resistance and a solo run. Applying these mappings across the register creates every required ITR as an empty record before any inspection is done, which gives you a true measure of scope and progress. For how ITRs sit alongside the ITP and checksheets, see ITP vs ITR vs checksheet.
The consequence is direct: a wrong tag type produces the wrong ITRs, and a missing tag produces none at all.
Linking to punch, certificates and documents
With tags in place, punch items are raised against tags, certificates are issued for subsystems made up of tags, and vendor and test documents are filed against tags. At handover, the handover dossier for each system can then be assembled from records that already know which system they belong to.
Keeping the tag register in sync with engineering
Engineering does not stop when construction starts. Tags are added, deleted, renumbered and reclassified through design revisions, vendor data and site changes. The completions tag register has to follow.
A workable sync process looks like this:
- Define the source of truth. Usually the engineering tool or engineering register is master for tag existence and technical attributes; the completions system is master for completion status.
- Set a regular import cycle. Weekly is common during peak engineering; less often later. Each import is compared against the previous one.
- Review the differences, do not just overwrite. New tags need a subsystem and ITR scope. Deleted tags with completed ITRs need a decision. Changed tag types may need ITRs added or removed.
- Control changes that affect certified scope. If a tag is added to a subsystem that already has an MCC, the certificate is no longer accurate. That should trigger a change process, not a silent update.
- Reconcile with the field. Walkdowns and construction queries will find items on site that are not in the register, and register items that were never installed. Feed these back to engineering.
The failure mode to avoid is two registers drifting apart: engineering's and completions', each believed by its own team. The longer that runs, the harder it is to reconcile.
Tag register checklist before construction ITRs start
- Tag numbering procedure issued and validated in the register
- All tags from P&IDs, instrument index, cable schedule, line list and equipment list loaded
- No duplicate tag numbers
- Every tag has a discipline, tag type and subsystem
- Tag type to ITR mapping agreed and applied
- Parent and child relationships set for packaged equipment
- Deleted and on-hold tags flagged, not removed
- Import and change process agreed with engineering
- Owner data requirements (for example CFIHOS classes) identified
Managing the tag register in Accord
Accord builds the project around a Project → System → Sub-system → Equipment/Tag hierarchy, so every tag rolls its completion status up to its subsystem and system automatically. Its equipment and items catalogue supports classes, custom fields, bulk import and export, and revision history, and its dual data model holds a CFIHOS asset taxonomy alongside the functional system breakdown. ITRs, punch items, certificates and documents are all linked to the same tags, and change requests with impact assessment and approval workflows help keep the register and certified scope aligned when engineering changes.
Frequently asked questions
What is the difference between a tag register and an asset register?
A tag register lists every tagged item defined by engineering and used through construction and commissioning. An asset register is the operator's list of maintainable assets, usually held in the maintenance management system. The asset register is often derived from the tag register at handover, but may group, filter or restructure tags to suit maintenance.
Who owns the master tag register?
Engineering usually owns tag creation and technical attributes, while the completions team owns completion status and subsystem allocation. On many projects the owner defines the numbering procedure and data requirements. Ownership should be written into the project's information or completions procedure.
Should cables and lines be in the tag register?
For completions purposes, yes. Cables need installation, termination and insulation-resistance records, and lines need pressure test and reinstatement records. Leaving them out means that inspection scope is tracked somewhere else or not at all.
What happens if a tag is added after mechanical completion?
The subsystem's MCC no longer reflects the full scope. The new tag needs its ITRs completed and should go through the project's change process, which may require the certificate to be revised or a supplementary record to be issued. Adding it silently leaves an uninspected item inside a certified system.
How do you find tags that are missing from the register?
Compare the register against every engineering source document, check for tags with no subsystem, and use walkdowns to spot physical items with no matching record. Instrument loops with only some of their devices registered, and packaged equipment with missing sub-components, are common gaps.
