Predictive maintenance on distribution assets is a well-understood modeling problem. Given a clean history of assets, interventions, conditions, and failures, the model is not the difficult part. The difficulty is that in most utilities those four things live in systems that do not agree on what an asset is.
Three systems, three versions of the truth
The asset register knows what was installed and, imperfectly, where. The work management system knows what crews did, recorded against a location that may or may not map to the register. The field documentation — photos, notes, inspection forms — knows what was actually there, in prose, sometimes contradicting both.
Every analytics effort begins by assuming these reconcile. They reconcile for the newest assets and degrade steadily going back, which is unfortunate because the failure history that carries the modeling signal lives in the older records.
The model wants twenty years of history. The data joins cleanly for four.
What reconciliation actually requires
It is entity resolution again, in a different costume. An asset is identified across systems by a combination of location, type, install date, and circuit, none of which is reliable alone and several of which change legitimately over time when equipment is relocated or a circuit is re-sectionalized.
- Resolve assets across systems on multiple signals, retaining match evidence
- Treat replacement as a lineage event, so a failure is attributed to the right unit
- Extract field-note content as structured, span-linked observations rather than free text
- Record which reconciliations are uncertain, and exclude them from training rather than guessing
- Keep the reconciliation versioned, so a model trained last year remains explicable
Field notes are the underused asset
The most valuable condition information in many utilities is sitting in crew notes and inspection comments, unstructured and unqueried. This is genuinely a good application for a language model — reading those notes and emitting structured observations with the span they came from.
The discipline is the same one that governs extraction anywhere the output feeds a decision. The model proposes a structured observation; the observation carries its source span; anything it asserts that is not in the note is rejected. Done this way the notes become a data source. Done as summarization, they become a plausible narrative about equipment that may not exist.
Where utility analytics programs lose their schedule
Relative weighting from delivery practice, not a measured statistic — shown to rank where attention belongs.
What this changes about project sequencing
A utility analytics program scoped as a modeling effort will spend its first two-thirds discovering the reconciliation problem and its last third rushing the model. Scoped correctly, the reconciliation is the first deliverable and it is independently valuable — a resolved asset history is useful to planning, to regulatory reporting, and to storm response whether or not a predictive model is ever built.
That sequencing also produces something to show early, which matters for a program that has to survive a budget cycle before it produces a forecast anyone acts on.
What the reconciliation actually looks like
Saying that three systems disagree is abstract. The disagreements have recognizable shapes, and naming them makes the work estimable.
| Disagreement | How it appears | Why it matters to a model |
|---|---|---|
| Identifier drift | The asset was re-tagged during a system migration | History splits into two assets, halving the observed life |
| Location as identity | Work recorded against a pole number, not an asset | Replacement units inherit the predecessor's failures |
| Silent replacement | A unit swapped in the field with no register update | Failure attributed to equipment that was removed years earlier |
| Circuit re-sectionalization | Topology changed; historical circuit references no longer resolve | Exposure and loading history become non-comparable |
| Bulk load artifacts | A migration assigned a default install date to thousands of assets | Age becomes a meaningless feature across a large population |
The last row is worth dwelling on because it is common and catastrophic to a model. A default install date applied during a system conversion creates a large population with identical, wrong age. Any model that finds age predictive will find it predictive for the wrong reason, and the effect is invisible unless someone plots the install-date distribution and notices the spike.
Lineage is the concept that makes this tractable
The unifying fix is to stop treating an asset as a row and start treating it as a lineage: a position in the network that has been occupied by a sequence of physical units, each with its own install, service, and removal events.
With lineage, a failure attaches to the unit that failed rather than the location. Age is computed from the unit's install date rather than the location's. Intervention history distinguishes work on the current unit from work on its predecessor. None of this is exotic data modeling, and its absence is the single most common reason utility failure models underperform on data that looks adequate.
Lineage also makes the uncertain cases explicit. Where the records cannot establish whether a replacement occurred, the lineage carries a gap, and assets with gaps can be held out of training rather than silently contributing noise. That choice is only available if the uncertainty was represented rather than resolved by a default.
Field notes: the largest underused source
Crew notes, inspection comments, and outage remarks contain condition observations that exist nowhere else — the corroded connector noted but not work-ordered, the tree contact observed on an adjacent span, the equipment that "looked fine but sounded wrong."
Turning this into data is a legitimate language-model application and it has a specific shape. The model reads the note and proposes structured observations: an asset reference, an observation type, a severity, and the span of text supporting it. A human confirms the ambiguous ones. The model is not asked to summarize the note, and it is not permitted to assert anything not present in the text.
- Observation type drawn from a controlled vocabulary, not free text
- Asset reference resolved through the same lineage layer as everything else
- Source span retained so any observation can be read in context
- Explicit unresolved state where the note references an asset ambiguously
- Confidence surfaced, with low-confidence extractions routed to review rather than dropped
Done this way the notes become a condition signal spanning years. Done as summarization they become a plausible narrative about equipment, which is worse than not doing it at all because it looks like data.
Sequencing that survives a budget cycle
A program scoped as "build a failure model" produces nothing visible for a long time and then produces a model whose weaknesses trace back to data problems discovered too late to fix.
A better sequence delivers the reconciliation first as its own product. A resolved, lineage-aware asset history with unified work and condition records is immediately useful to planning, to regulatory reporting, to storm restoration, and to rate case support — none of which require a model.
That gives the program a deliverable in its first phase, a reason to continue funding it, and a foundation whose quality is visible before anyone bets a maintenance budget on a prediction. It also front-loads the discovery of data problems to a point where they can still change the plan.
What to check before trusting any result
Three diagnostics catch most of what goes wrong, and all three are cheap.
Plot the install-date distribution and look for implausible spikes, which reveal bulk-load artifacts. Plot observed asset life and look for a cluster at exactly the age of the oldest record system, which reveals censoring being read as failure. And sample twenty assets the model ranks as highest risk, pull their full record by hand, and have someone who knows the system read them.
That last check is the most informative hour in the entire project. It reliably surfaces either a data problem the metrics did not show, or a genuine pattern the team can then explain — and either outcome is worth the hour.
The reconciliation pays for itself before any model does
Programs justified solely on predictive maintenance carry all their value at the end, which makes them fragile to a budget cycle. The resolved asset history is worth real money on its own, and saying so changes how the program is funded.
- Storm restoration — knowing what is actually installed where shortens damage assessment
- Regulatory reporting — reliability metrics computed from a reconciled history are defensible
- Rate case support — capital planning arguments rest on asset age and condition evidence
- Vegetation and inspection targeting — condition observations from notes become a queryable signal
- Warranty and recall — finding every unit from a given manufacturer and batch stops being a project
Any two of those justify the reconciliation without reference to a model, which is the argument that survives a lean year.
What to do when the history is genuinely too thin
Sometimes the honest finding is that reliable failure history covers too short a window to support the model that was requested. Reporting that is more useful than delivering a model fit on four years of censored data and letting the operating decisions rest on it.
The productive alternatives are narrower and real. A condition-based ranking from inspection and field-note evidence requires no failure history at all. A survival model on a well-understood asset class with a physical failure mode can borrow structure from engineering knowledge rather than data volume. And instrumenting for the next five years — deciding now what will be recorded — is frequently the highest-value deliverable of the whole engagement.
Who owns the reconciliation afterward
Asset records drift because the field changes faster than the systems. A reconciliation delivered as a one-time project degrades from the day it ships unless the operational processes that create the drift are addressed alongside it.
That means the deliverable is partly procedural: how a field replacement gets recorded, who closes the loop when a work order references an asset that does not exist, and what happens when a circuit is re-sectionalized. These are not analytics questions and they determine whether the analytics stay true.
Frequently asked questions
Sometimes, and it is a reasonable first version. The limitation is that failure events are rare, so a short window may contain too few to learn from. That trade should be measured, not assumed either way.
No. The lineage and relationships can be represented in a relational schema without difficulty. The requirement is that lineage exists and is versioned, not the storage technology.