The object behind the row
This October 2026 revision returns to a basic question in the original article: what work should an asset register make possible? A complete-looking spreadsheet can still leave an operator unable to locate the object described by a row. The identifier may exist only in the office. The field label may have changed. Several components may share a location while requiring different interventions. The register becomes useful when its identity can survive the journey from a planning screen to the physical object and back to a completed work record.
That journey should determine the initial fields. A person needs to identify the object, distinguish it from its neighbours, understand the relevant condition and find the current instruction. Additional detail may be valuable, but it should have a purpose and an owner. A field filled once for an import and never checked again can create more confidence than knowledge. The review should ask which decisions depend on each important value and how the organisation will detect that the value has become inaccurate.
Identity survives a change in description
The name of an asset can change without the asset itself being replaced. A location description can improve after a survey. A classification can be revised to support a different maintenance plan. These changes should not create a new physical object by accident. Conversely, replacing a component at the same location should not automatically inherit the entire history as though nothing changed. Stable identity requires a rule about what counts as the same object. That rule is a practical operating choice and should be documented where the choice affects inspection or replacement.
PRIMA provides a useful current example. A façade matrix may contain tiles, and a tile may contain units that are separately replaceable. The right level of identity depends on the intervention. If maintenance replaces a complete tile, a unit-level register may be unnecessary for routine operation. If individual units are diagnosed and changed, the history needs that finer boundary. The current component diagram is a proposal for discussing these levels. It does not establish the final maintenance model. That model should follow the replacement test, not precede it as an unexamined database assumption.
Condition is an observation with a date
An asset's condition should not be treated as a timeless characteristic. It is an observation made under particular circumstances. An inspection may have limited access or may cover only the visible portion. A report should retain those limits. The next inspection can then confirm, revise or challenge the earlier observation. Overwriting a condition field without retaining the observation history removes the sequence needed to understand deterioration, repair or inconsistent assessment. A current summary is useful, provided the reader can recover the evidence from which it was derived.
The same distinction applies to readiness. A vehicle can be physically present but unavailable for service. A tile can be powered but awaiting a configuration check. A road segment can be accessible while an intervention remains incomplete. A register should not force these conditions into a single active flag. It needs a small set of states that correspond to real operating choices. Too many states become difficult to apply consistently; too few conceal the work. A pilot should test the vocabulary against ordinary ambiguous cases before extending it across the portfolio.
Measure whether the register helps
A practical review would ask a colleague to use a sample of records to plan and close a real task. Can they find the object without an informal explanation? Do the instructions refer to the correct assembly? Can they record a replacement without erasing the earlier history? Can another person later understand the result? These questions test the register as a working tool. Counting completed fields may support that review, but it cannot replace it. A perfectly populated field that refers to the wrong physical object remains a defect.
For Meridian and Relay, the next improvement should begin with a bounded operating sequence and a manageable sample of assets. Record the mismatches, identify their causes and revise the identity or update rule. Avoid promising a single permanent master record that will remove all uncertainty. Physical systems change, and knowledge about them changes too. The register's value lies in making those changes legible enough for the next intervention. It is successful when the organisation spends less effort rediscovering what it already knows and can see clearly what still needs to be checked.
Sources and data notes
- PTD Capital LLC — PRIMA component boundaries2026 · Current example of component identity and replacement boundaries.