Industry Use Cases / WORKED EXAMPLE
Is the maintenance warning useful?
Compare detection, useful lead time and the work an alert creates.
READ THIS WITH ONE QUESTION
Does the warning arrive early enough for a useful action, within the review budget?
For: maintenance leads, reliability engineers and pilot owners.
Your output: a bounded maintenance pilot decision.
Illustrative data created by Industry AI Decision. These are teaching scenarios, not customer results or product benchmarks. Version 1.0 · 25 September 2026.
01 / WORKING DATA
Count useful warnings, not repeated notifications.
Scope: one pump family and one bearing failure mode. Each row is one pre-defined, non-overlapping observation episode; six end in a confirmed failure.
Counting rule: collapse repeated notifications in an episode into its first warning. “—” means no warning. All records below are fictional.
Useful lead time: at least 8 hours before failure.
Review budget: 15 minutes per warning, with 120 minutes available for the full observation period. Inspections and repairs require additional time.
| Episode | Failure occurred | AI warning lead time (h) | Current-rule lead time (h) |
|---|---|---|---|
| E01 | Yes | 12 | 9 |
| E02 | Yes | 10 | — |
| E03 | Yes | 6 | 3 |
| E04 | Yes | — | — |
| E05 | Yes | 9 | 8 |
| E06 | Yes | 8 | — |
| E07 | No | False alert | False alert |
| E08 | No | False alert | — |
| E09 | No | — | — |
| E10 | No | False alert | — |
| E11 | No | — | — |
| E12 | No | — | — |
02 / YOUR TURN
Which approach supports the next pilot?
Count warnings, detected failures, failures warned at least 8 hours ahead, and review minutes. Does the AI meet the review budget? Does that prove it prevented downtime?
Show the calculation and answer
AI: 8 warnings, 5 of 6 failures detected, 4 of 6 warned in time. Event recall = 5/6 = 83.3%; warning precision = 5/8 = 62.5%; timely failure coverage = 4/6 = 66.7%. Initial review = 8 × 15 = 120 minutes.
Current rule: 4 warnings, 3 of 6 failures detected, 2 of 6 warned in time. Recall = 50%; precision = 75%; timely coverage = 33.3%; review = 60 minutes.
The AI gives 2 more timely warnings at an extra 60 minutes of review. It uses the entire review budget. These 12 constructed episodes establish no real-world performance estimate or avoided downtime.
03 / COMPLETED EXAMPLE
Decision: test the response workflow in shadow mode.
| Decision field | Example entry |
|---|---|
| Scope | One pump family, one bearing failure mode, read-only warnings. |
| Owner | Maintenance lead reviews alerts; technician authorizes inspection. |
| Evidence | Compare both rules on the same later observation period with complete failure follow-up. |
| Gate | Agree an initial-review budget, minimum useful lead time and acceptable missed-event rate before the pilot. |
| Stop / investigate | Review queue exceeds its budget, timestamps are unreliable, or a critical event is missed. |
| Next action | Run a shadow review with no automatic equipment control; record whether each timely warning led to a feasible action. |
A warning can be correct and still arrive too late. Separate alert quality, response feasibility and realized benefit in your review.
04 / USE YOUR OWN DATA
Turn the exercise into a working assessment.
Start with the maintenance pilot checklist. Replace the episode sample with complete, time-aligned records. Use Alert Trade-off Analyzer for detection counts and Reliability & Downtime Calculator for actual operating, failure and repair records. The event table above is not an MTBF dataset.
For the AI example enter TP 5, FP 3, FN 1 and TN 3. Leave costs blank until you have evidence. Set Input evidence to Estimated and note “synthetic training example”. Do not interpret the toy sample as your plant’s failure rate.
Copy these fields into your own brief: asset family; failure definition; episode window; current rule; AI rule; useful lead time; review budget; owner; observation period; action log; decision and unresolved evidence.
Method: classification metrics and evaluation with appropriate data splits. The lead-time gate and operational steps here are proposed editorial examples.
Keep a copy for your team. Print this guide or choose Save as PDF in your browser. The answer panels open when you use the button below.
A COMPLETE FREE PROJECT / FICTIONAL DATA
From first question to follow-up
Project: Compressor A downtime review. Goal: understand unplanned downtime before approving a broader maintenance pilot. Owner: maintenance lead. The figures below illustrate a process, not a verified customer outcome.
| Stage | Question / record | Next action |
|---|---|---|
| Baseline | In a 200-hour period: 190 operating hours, 4 failures and 10 hours of unplanned downtime. Which work orders support these inputs? | Save the Reliability & Downtime result, including the observation dates and evidence note. |
| Evidence gap | Two work orders have incomplete failure codes. Are planned maintenance hours consistently excluded? | Assign an action to reconcile logs and document the downtime boundary before interpreting change. |
| Action | Maintenance lead completes a focused inspection and records what was changed. Review after the next comparable 200-hour period. | Add the action, proof required, due date and outcome to the saved result. |
| Follow-up | Previous answers are prefilled. Confirm the same asset and boundary. Update to 194 operating hours, 3 failures and 6 hours of unplanned downtime, with new dated evidence. | Choose Follow-up, state changes and confirmations, and save a new result. Keep the baseline. |
| Review | The observed downtime share is 5% versus 3%, a reduction of 2 percentage points. Was workload or failure mix different? | Review confounding changes and missing evidence. The difference alone does not prove the action caused improvement. |
| Human decision | Continue one more observation period; do not approve a wider rollout on this evidence alone. | Record the rationale and next review date in My Projects. |
Questions should continue from the previous review
At baseline: What is the problem, boundary, owner, current measure and evidence source?
At follow-up: Which previous answers are still valid? What action was completed? What evidence changed? Which assumptions remain unknown?
When scope changes: Use a new baseline or an alternative scenario. Do not present it as improvement in the original series.
Create your project → · Try the Reliability & Downtime Calculator → · Read the full member walkthrough →