checklist

Predictive Maintenance Data Readiness Checklist

A practical, interactive readiness checklist to evaluate sensor, label, timestamp, sampling, and data-quality requirements before launching a predictive maintenance (PM) pilot. Includes focused diagnostic checks, pilot metric guidance, and a simple readiness score to help decide whether to proceed, iterate on data work, or widen scope.

Interactive Tool

Predictive Maintenance Data Readiness Checklist

Use this checklist before investing heavily in a predictive maintenance pilot.

This interactive checklist helps you quickly assess whether your assets, sensors, labels, timestamps, and storage are in a state that will produce meaningful evaluation results. Answer each item, add brief notes, run the diagnostic checks described in the help text, and use the readiness score to guide next steps.

Recommendations embedded in help text assume typical rotating equipment or process sensors; adapt thresholds and metrics to your equipment, risk tolerance, and business case.

Are all pilot assets uniquely tagged and mapped to the CMMS/ERP asset IDs?

Unique asset IDs are required so sensor streams can be linked to failure, maintenance, and work-order history. Target >90% of planned pilot assets tagged. If NO, list percent tagged below.

Percent of planned pilot assets correctly tagged (0-100)

Enter the percent of pilot assets that are already tagged and mapped. Aim for 90%+ for meaningful pilot evaluation.

Are timestamps synchronized across sensors and systems (same timezone/epoch and drift <1s/day)?

Synchronized timestamps are essential. Check NTP/PTP status, sensor clock behavior, and ingestion pipeline timezones. If unsure, run quick alignment diagnostics described in the diagnostics help below.

Describe typical sampling rates for sensors in the pilot (Hz or interval):

List sensors and their sampling frequency or interval (e.g., vibration: 512 Hz, temperature: 1/minute). Indicate whether raw high-frequency data or aggregated features will be available.

Does sampling frequency meet the physics / failure-mode needs?

Consider Nyquist-style thinking: vibration features often require high-frequency sampling; slow-changing signals (temperature) can be lower-frequency. If NO, note which sensors need frequency changes.

Is there sufficient historical data and retention to cover representative failure/normal windows?

A good pilot typically needs several months to years of data depending on failure rate. If failures are rare, consider synthetic events, focused inspections, or longer collection windows.

Estimated months of usable historical data available (enter number)

Enter the approximate months of continuous, usable data per asset required for model evaluation.

Is the approach for handling missing or intermittent data defined (and acceptable)?

Document expected sources of missingness (sensor outages, network loss), acceptable thresholds (e.g., <5% missing expected), and imputation or exclusion rules.

Maximum acceptable percent missing per timeseries (0-100)

Set a threshold that, if exceeded, will disqualify a sensor stream from model training/evaluation.

Are failure / event labels defined, consistently applied, and linked to timestamps?

Labels must be precise and linked to timestamps or intervals (e.g., failure start, failure confirmation, maintenance action). Define label schema: ‘failure’, ‘near-failure’, ‘maintenance’, with clear inclusion rules.

Estimate label quality (1-poor to 5-excellent)

Consider accuracy, consistency, and coverage. Low-quality labels reduce model usefulness; consider manual relabeling or rule-based labeling where practical.

1.0 10.0

Percent of failure events with usable labels (0-100)

High coverage is needed for supervised learning. If coverage is low, consider unsupervised or anomaly-detection approaches or invest in label capture.

Will you have access to raw signals or only precomputed features?

Raw signals enable richer feature engineering but increase storage and compute needs. Precomputed features may limit model choices.

Have you run the quick diagnostic checks (timestamp drift, missing patterns, distribution drift, basic correlation)?

Use the diagnostic snippets below to verify key assumptions. See the 'Quick Diagnostic Checklist' help box for sample commands and expected results.

Diagnostic results and next actions (brief):

Summarize findings from diagnostics: major gaps, sensors needing fixes, or unexpected patterns. Note owners and target fix dates.

Is the data collection and storage compliant with privacy and security policies (and any regulations)?

Confirm data ownership, access controls, masking/anonymization where needed, and that stakeholders accept data transfer plans.

Are the pilot success metrics defined (detection lead-time, false alarm rate, precision/recall, business KPIs)?

Define both technical metrics (AUC, precision@k, mean time to detection) and business metrics (cost avoided per detection, reduction in unplanned downtime). Describe them below.

List primary pilot metrics (brief):

Example: detection recall >= 0.8 within 7 days lead-time, false alarm rate < 1 per asset-month, business ROI threshold, or cost-per-true-detection budget.

Overall readiness score (1-5)

1 = Not ready (major data gaps); 3 = Some gaps but actionable with defined fixes; 5 = Ready to pilot and evaluate reliably.

1.0 10.0

Additional notes, blockers, owners, or next steps:

Capture quick action items (e.g., sync clocks, increase sampling, relabel events, add storage), responsible owners, and target dates.

You can explore this tool now. Sign in or create an account to save your responses and return to them later.

Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.

Discuss Ask the Librarian

Discussion

Comments and conversation will live here.

Predictive Maintenance Data Readiness Checklist