Data-quality dimensions
| Dimension | Question | Example check |
|---|---|---|
| Completeness | Is a required value present? | Percent of active assets with a parent and location. |
| Validity | Does the value obey its field rule? | Installation date parses and is not after the observation date. |
| Uniqueness | Does one real entity have one identifier? | No duplicate active asset IDs. |
| Consistency | Do related fields and records agree? | Asset status, hierarchy, and PM assignment do not conflict. |
| Accuracy | Does the record match independent evidence? | Sample make, model, serial, and location against the nameplate. |
| Timeliness | Was the record updated when the event changed? | Retired asset status and work-order closeout dates reflect the actual event. |
Asset-register fields
| Field | Working definition | Control |
|---|---|---|
| Asset ID | Stable unique identifier for one maintainable item. | Unique, nonblank, immutable or change-controlled. |
| Parent | Immediate higher-level asset or functional location. | Parent exists; no circular relationship. |
| Location | Controlled physical or functional placement. | Uses the approved hierarchy and effective date. |
| Asset class | Controlled equipment category. | Definition and allowed values are documented. |
| Make / model / serial | Manufacturer identity fields, kept separate. | Sample against nameplate or controlled source. |
| Criticality | Current local decision class and its method version. | Do not infer from incomplete text; review on change. |
| Installation date | In-service or installed date under a declared convention. | Document approximations and date basis. |
| Maintenance status | Applicable PM template, explicit no-PM decision, or other controlled state. | Do not treat blank as an approved run-to-failure decision. |
Work-order closeout fields
At minimum, define asset identity, observed problem, cause or controlled unknown, remedy, actual labor, parts used, downtime boundary when applicable, verification, follow-up, timestamps, and accountable closeout. Required fields must vary by work type; an inspection, breakdown, calibration, and administrative order do not need identical records.
Failure-code layers
| Layer | Question | Example |
|---|---|---|
| Problem | What was observed? | Leak, no output, high vibration. |
| Cause | Why did it happen? | Wear, misalignment, contamination, not determined. |
| Remedy | What was done? | Adjusted, cleaned, repaired, replaced. |
Migration evidence
Retain a dated source export and record counts; an approved source-to-target map; transformation rules; rejected-record log; test-import results; reconciliations for counts, relationships, dates, PM triggers, open work, and permissions; rollback and archive decisions; cutover acceptance; and post-go-live exceptions.
Declared ReliabilityBench thresholds
90–100% = ready for controlled use; 70–89% = review before use; below 70% = remediation required
These bands support triage only. Any critical missing field, failed relationship, unsupported cause, or migration blocker can override the percentage. Organizations must set their own acceptance rules based on intended decisions and risk.
Sources and related tools
Field themes follow public guidance in the UK Government FM Asset Data Standard and failure-record quality discussion in IAEA TECDOC 1922. See the CMMS data readiness guide for workflow and the tool cluster for interactive screens.