Product · Intelligence · Data quality
Open one asset record, field by field, blanks included.
MaxIron AI Smart Data profiles a class, proposes the classification, hierarchy and duplicate decisions with the evidence behind each, and declines the ones the estate cannot support. A named analyst accepts; Data Loader applies. No model writes to IBM Maximo.
The artefact
One record before the pass, and after it
Three fields changed, two declined, three carried unchanged. The Set by column is the point: every new value names the person who accepted it, and every refusal says why.
Asset A-104772, centrifugal pump
3 of 8 fields changed
| Field | Before | After | Set by |
|---|---|---|---|
| ASSETNUM | A-104772 | A-104772 | Unchanged. Carried intact through three predecessor systems. |
| DESCRIPTION | PMP CENT 3IN DISCH SEAL LK | PMP CENT 3IN DISCH SEAL LK | Retained in full. SEAL LK reads as a recorded condition, not an asset property. |
| CLASSIFICATION | Empty | Pump, centrifugal, in your own class hierarchy | Data lead, as one decision covering the whole cluster. |
| DISCHARGE_SIZE | Empty | 3 inch, in the unit convention this class uses | Data lead, in the same group decision. |
| PARENT | Empty | The parent used by the other rotating equipment at this location | Rejected on the first pass, accepted after one rule correction. |
| MANUFACTURER | Empty | Empty | Declined. Nothing in the estate implies a maker. |
| CRITICALITY | Empty | Empty | Declined. Consequence of failure is an engineering judgement. |
| WORKORDERS | Eleven across nine years | Eleven across nine years | Unchanged. The basis for making this record the duplicate survivor. |
Illustrative record and values.
Every inference, attributed
Five proposals, and what each was read from
The basis and the confidence sit beside the value, so a reviewer challenges evidence. One entry proposes nothing.
| Ref | Proposal | Read from | Confidence | Accepted by |
|---|---|---|---|---|
| P1 | Classification: pump, centrifugal | An abbreviation pattern shared with a large cluster in this class, and the job plans historically applied to those records. | High | Data lead, by group |
| P2 | Discharge size: 3 inch | The token 3IN in the description, read against the unit convention on records in this class that already carry the attribute. | High | Data lead, same group |
| P3 | Parent asset | The hierarchy pattern on sibling records at this location. Locations survived migration; asset parents did not. | Medium, flagged as medium | Rejected, then accepted after one rule correction |
| P4 | Survivor of the duplicate group | This record carries nine years of work orders. The two others describing the same pump carry none. | High | Data lead, by group |
| P5 | Nothing, on the tokens SEAL LK | A recorded condition rather than an asset property. Filling it would tidy the record and cost accuracy. | Not applicable | No proposal to accept |
In production on MaxIron data migration and improvement programmes across utilities, transport, manufacturing, oil and gas and building materials, data-facing half of the MaxIron intelligence layer, with Assist user-facing and Data Loader for applied changes at scale.
The blanks, on purpose
Four fields left empty, and the work that fills them
Attributes are proposed from estate data and approved reference records only. These four come back to you as named work with a cost, rather than as invented values.
- Manufacturer, model and serial
- Nothing in the estate implies a maker, so the field returns as a walkdown or a nameplate photograph. A field cost on your side.
- Criticality
- Consequence of failure is an engineering judgement. One decision per class, then applied; knowing which records wait on it is most of the work.
- Preventive maintenance regime
- Which PM applies is a reliability decision. The record becomes fit for that decision without taking it.
- Which duplicate survives, where both are in use
- Where both records are live in the business, the survivor is an operational choice and stays with a person at each site.
The class around the record
A-104772 was one of roughly 4,100
- 4,100
- Records in the class
- 300
- Records in duplicate groups
- 1
- Rule corrected, whole group re-proposed
Illustrative profile of one rotating equipment class, taken before any proposal, so the size of the problem is counted rather than estimated.
Illustrative. Each group carries a proposed survivor and the reason, so the data lead accepts most of a group in one decision.
Illustrative. One rule misread a local abbreviation, the group was rejected, the rule corrected once, and the group came back.
From proposal to applied change
Two gates on the way into the estate
At no point in the teardown above did a model update the register.
- 01
Profile the class
Populated fields, naming patterns, duplicate groups and the records too thin to work from, all counted before anything is proposed.
Owner MaxIron, with your data lead Typically Days, per class
- 02
Gate one: an analyst accepts
Every change stays a proposal until a named analyst accepts, edits or rejects it by group with the evidence in view. Rejecting a group corrects a rule rather than a record.
Owner Your data lead and analysts Typically Set by review capacity
- 03
Gate two: Data Loader applies
Accepted changes reach the estate through MaxIron Data Loader: templated structure, validation, preview, and a record of who changed what and where. Extraction for reporting runs the same path in reverse.
Owner The same team, in a controlled tool Typically Per accepted batch
Scope and boundaries
Three limits worth knowing before you scope this
Each of these has shaped an engagement already.
It cannot invent what your estate does not hold
A record whose description is PUMP alone has nothing to enrich from and is set aside as a named list. Those records become walkdown, nameplate or engineer interview work: a field cost, often large on a poor class.
Your review capacity sets the pace
Proposals arrive faster than any team accepts them. Where the data lead has one day a week, that is programme throughput, and planning as though software were the constraint will skew the timeline.
It does not fix the reason the data drifted
Without a changed process and an owner for the standard, the same conversation returns in three years. That is ownership work, usually alongside business process optimisation.
MaxIron AI Smart Data, frequently asked questions
- Can it write to Maximo directly?
- No. A named analyst accepts proposals, then Data Loader validates and applies what was accepted, with preview and an audit record. Unaccepted proposals change nothing.
- How accurate are the suggestions?
- Each proposal carries its basis and confidence, and the analyst who accepts it stays accountable. The meaningful figure is measured on your records against your standard.
- What happens to the records it cannot work out?
- They are set aside and returned as a list, usually for a site walkdown. Knowing which records need it is much of the value.
- How is this different from MaxIron Data Loader?
- Data Loader applies data into IBM Maximo with templates and validation. AI Smart Data decides what the data should say. It proposes; Data Loader applies.
- Who can see the data, and what is retained?
- Agreed with your security team before engagement: what is processed, where it stays, retention and access. Every acceptance is attributable to a named analyst. See enterprise AI governance.
Send us five hundred rows of your worst class.
One export of a single asset, location or item class exactly as it stands. We take a handful of records apart as above: the proposal, the evidence, the confidence, and the fields we would refuse to fill.
Bring this to the first call
- One export of a single class, around five hundred rows, as it stands
- Your classification standard, if one exists, in whatever form
- Realistic analyst days per week available for review