Skip to main content
All field notes
Field workflow

Building an equipment register that survives

2026-05-12 · 6 min read · By Kash Mohammed, President

Every inspection record, thickness reading, and repair history hangs off one thing: the identity of the equipment it describes. If that identity is unstable, everything above it is unstable. A twenty-year thickness trend is worthless if nobody can prove the readings describe the same vessel under three different tag conventions.

Most registers do not fail loudly. They decay.

How registers rot

  • The spreadsheet fork. The register starts in the CMMS, then someone exports it to plan a project. The export gains columns, gets shared, and becomes the version people trust. Two years later there are five registers and a standing argument about which is current.
  • The rename without a trail. A unit gets redesignated, a merger imposes a new tag scheme, and V-101 becomes 23-VE-1001. If the old identity is overwritten instead of linked, every historical record referencing V-101 is orphaned.
  • The granularity mismatch. The CMMS tracks maintainable assets; inspection needs pressure boundaries, circuits, and CMLs. When the register only knows exchangers, thickness data for the shell, channel, and bundle piles into one bucket and corrosion analysis turns to mush.
  • Physical drift. Equipment gets replaced in kind, relocated, or rerated, and the register learns about it months later, if ever. The record now describes a vessel that left the site on a truck.
  • The retirement that never happens. Decommissioned equipment lingers active, inflating overdue-inspection counts until people stop trusting the overdue list at all. A list nobody trusts is a list nobody works.

Principles of a register that lasts

  1. One system of record, and everything else is a view. Exports for analysis are fine; exports that accept edits are how forks are born. Changes flow back to the register or they did not happen.
  2. Identities are permanent; names are attributes. The register key never changes. Tags, descriptions, and unit assignments can be renamed freely because they hang off the identity rather than being it. The full alias history stays queryable, so a 1998 report referencing the old tag still resolves.
  3. Hierarchy down to where data lands. Site, unit, system, equipment, component, CML. The register must reach the level at which measurements are actually taken, because that is the level at which history must be comparable.
  4. Change is an event, not an overwrite. Rerates, replacements, and relocations are dated events on the identity. A replacement in kind starts a new thickness baseline while keeping the lineage; anything less quietly corrupts corrosion rates.
  5. Field verification built in. The people standing in front of the equipment are the best auditors the register will ever have. Give them a low-friction way to flag a mismatch, wrong tag, missing nameplate, vessel not found, and route the flag to someone whose job includes resolving it.
  6. Retirement is a workflow. Decommissioning updates status, closes open schedules, and preserves history as read-only. The overdue list stays honest.

The survival test

Registers are proven by turnover. The engineer who knew that the register calls it E-204 but the field calls it the old glycol exchanger will retire. If that knowledge lives only in their head, the register fails the day they leave. A durable register is one a competent stranger can navigate: from a tag stenciled on steel to the identity, its hierarchy, its alias history, and its complete record, without asking anyone.

Run that test on one awkward piece of equipment this week and see how far a stranger gets.

intelliTRACK maintains equipment identity with hierarchy, alias history, and field-flagged corrections, so the records built on top of it in intelliINSPECT and intelliNDT stay attached to reality. Bring your register's messiest corner to a demo.

Referenced on intelliSPEC