Almost every Polish page about predictive maintenance explains what it is. Almost none answers the practical question: does this particular plant have anything to predict from today? The answer does not depend on which model somebody proposes to you, but on what is sitting in your ticketing system and in your control system.
The definition in two sentences. Prognostics is the prediction of what has yet to happen, whereas assessing a machine’s condition today is what the standards call diagnostics (NIST, report NISTIR 8012 from 2014, read on 8 September 2026). In Polish the first of those is called predykcyjne utrzymanie ruchu, or konserwacja predykcyjna.
None of this is a new claim. ASTOR, a Polish industrial automation supplier, writes that “the foundation of effective prediction is prevention that works well” (17 March 2025), and that without a history of failures, inspections and repairs AI “will merely be guessing” (a piece on AI in maintenance, 21 July 2026; both pages read on 8 September 2026, both quotations translated from Polish). This post starts where those two end: at the two files that have to be joined into one.
To be plain about where we are writing from: we do not sell predictive models. We build failure registers, assistants over technical documentation and repair history, and data audits — the things that come before prediction, and often instead of it. If the test comes out as a “no” at your plant, we have nothing to put in place of a model except a project that will build that history first.
The one-afternoon test: two exports covering the same period
The whole test comes down to one instruction: export twelve months of signals and the failures from the register for the same period — for one machine, or, if you have several identical ones, for that whole class. The more general version — the last hundred cases of any process as a single table — is in Step 3 of the guide to implementing AI. With machines, a hundred cases usually do not exist, and the difficulty lies in joining the two files into one.
The reason it is those two comes from the standard. A prognosis — as ISO 13381-1 of 2015 understands it — rests on knowing the expected failure modes and the duties placed on the machine; the standard adds that this may call for what it terms run-to-failure data: records of runs that ended in a failure (read on 8 September 2026; the edition was superseded in 2025). Microsoft’s reference architecture (Predictive Maintenance Architecture With Real-Time Intelligence, learn.microsoft.com, 12 February 2026) names those same sources outright: the CMMS, and PLC controllers and SCADA systems.
Five questions that settle whether predictive maintenance is feasible at your plant
1. Does a failure register exist — and can it be turned into a table?
“Yes” holds only where somebody can produce, in fifteen minutes, a file in which one row is one failure. The person to ask is the maintenance manager; the proof is an export from the CMMS or a spreadsheet, carrying the machine identifier, the moment the failure occurred and the moment it was resolved.
“No” usually looks like this: the register is a notebook in the workshop, or it does sit in a system but the fault description field is free text and half the entries read “failure”. A free-text field does not disqualify a register; it moves the work — somebody has to reduce those descriptions to a finite set of failure modes. That is work done once, not an insurmountable obstacle.
2. Do the events carry timestamps you can trust?
“Yes” means the register holds the moment the failure occurred, not the moment somebody noticed it or typed it into the system. The person to ask is whoever administers the CMMS; the proof is a column with the time of the event — and if every value in it coincides with the start of a shift, what the register holds is the shift time, not the failure time.
This is not a dig at Polish plants. The problem is described by a Microsoft engineer, John Ehrlinger, in the archived guide Care and Feeding of Predictive Maintenance Solutions: a failure is often recorded only during a service visit, which makes it harder to establish when it actually occurred (learn.microsoft.com, 23 January 2018, read on 8 September 2026). The same guide adds that inspection records support the inference that the machine was operating correctly at that point.
3. Can the signals be exported — at machine level, not line level?
“Yes” means there is a file holding the measurement history of that one machine, with a date and time against every value. The person to ask is your controls engineer, or your SCADA supplier: are those values archived anywhere, and how far back. One further condition rides on that answer: the archive has to hold a parameter that carries the symptom of the failure mode you chose in question one, sampled often enough to show it — an archive of the wrong parameter, or one value a shift, is a “no” wearing the clothes of a “yes”.
“No” comes in three forms. The controller knows the current value but nobody stores it — a PLC is not a historian. SCADA does archive, but reports at line level, so you cannot attribute a trace to the machine that stopped. The sensor gateway overwrites older measurements — how far back it reaches is the first thing to ask its supplier.
Before anybody starts talking about purchases, it is worth doing what ISO 17359:2018 recommends in §8.3: check whether the parameters of interest are already measured by existing supervisory or control systems. AndonCloud makes the same point in Polish — predictive maintenance “does not always have to start with expensive IoT sensors” — and points to workstation statuses, OEE indicators and downtime durations (page with no publication date, read on 8 September 2026, quotation translated from Polish).
4. Do both sides carry the same machine identifier?
“Yes” means the machine identifier from the register appears in the signal export in the same form, with no translation in somebody’s head. A model learns neither from the register nor from the signals on their own — it learns from the join. Among the seventeen Polish pages we read while writing this, not one asks this question, and it weighs more in a project than the choice of algorithm.
| What the model has to assemble into one pair | Where it comes from |
|---|---|
| The event: machine identifier, moment of occurrence, failure mode | the failure register — CMMS, spreadsheet, ticketing system |
| The window of signals immediately preceding that moment | historian, SCADA, sensor gateway, controller with archiving |
Illustrative table, no real data: the pair either forms or does not form at the level of a single machine.
Four things break that join, and you will see all four within fifteen minutes of opening both files.
- No shared identifier. The register uses inventory numbers, the historian uses tag names, and no table linking one to the other exists. ISO 17359:2018 recommends in §8.8 that measurement points be unambiguously identified, with permanent marking.
- A timestamp too coarse, or from the wrong clock. The start of the shift instead of the time of the event; a clock other than the one stamping the signals.
- The date of the visit instead of the date of the failure. This specifically ruins the window labelled “before the failure”.
- A change of load taken for a fault. The standard notes in §8.4 that a change in a parameter caused by a fault must be distinguishable from one caused by a change in operating conditions — and without knowing what the machine was doing at the time, a changeover looks in the data like the onset of a failure.
Here is how that looks in practice. A plant with a hundred and twenty staff, a CMMS from 2022, SCADA reporting at line level; everyone certain the data for prediction was there, because the register held three years of entries. The project was stopped by the fourth question: the CMMS worked in inventory numbers, SCADA in tag names, and the mapping between them existed nowhere but in the head of one controls engineer.
A composite from several audits, not a description of one client. The numbers are illustrative and show the structure, not the market.
5. How many events of the same type does that class of machines have on record?
The number of events, not the number of months — that is the unit to count in, and it is what separates a ready plant from an unready one with an equally long register. The proof is a single number: how many times that particular failure mode appears in the CMMS export you asked for in question one.
The reason is methodological. Predicting failures from your own machines’ history is supervised learning: as Microsoft’s guide describes it, you hold the complete life history of a series of devices and characterise from it how others — unseen, but taken to be identical — would behave. A fleet of twenty identical pumps is twenty histories of the same device; a one-off press is one history and no device to carry the result across to. Machines that did not fail count too — the same guide recommends using devices both with and without failures, because only together do they help tell the two behaviours apart.
We will not give a threshold, because for your press no true threshold exists. We will give the unit: the number of recorded events of that failure mode within one machine class. Among the pages we read, those that give a figure here give time — codescriptum, the only one with a plant-readiness checklist of its own, asks for a failure history of “min. 12 months” (20 April 2026), AndonCloud for “a minimum of a year” (no publication date); both read on 8 September 2026, both quotations translated from Polish. Both figures are reasonable approximations and both measure the wrong thing: months are a consequence, not a condition — they follow from how often that machine breaks down.
In the example from question four, that turned out to be the most interesting part. For the press the conversation started with, the failure mode of interest had occurred three times in a year; for twelve identical pumps nobody was thinking about, because “they rarely break”, it was several dozen. The machine a conversation starts with is rarely the machine a project should start with.
Threshold alarms, anomaly detection and failure prediction are three different things
A threshold alarm is a rule somebody typed in. The threshold value is derived from standards, manufacturer guidance and experience, and warning thresholds are set below the alarm threshold — that is how NIST describes it, reporting ISO 13381-1 (NISTIR 8012 from 2014, read on 8 September 2026). This mechanism needs no failure history, because it learns nothing.
Anomaly detection builds a model of normality out of the signals alone and raises an alarm when a trace departs from it — without a single recorded failure. Microsoft describes it as the typical approach where a plant is operating reactively, and writes that it can be more accurate than simple threshold rules (the same archived guide). Which is to say: a thing worth buying precisely where prediction is not yet being done.
Failure prediction requires pairs: an event, and the window of signals that preceded it. It is a supervised method, so the labels have to come from somewhere — and for a plant predicting its own machines, that somewhere is the failure register.
Hence a correction to the most common promise on the market. Staleo walks the reader through an implementation model in which “collecting data” takes “a few weeks”, and gives “a 20–40% reduction in downtime” with no study or source cited (15 May 2026, read on 8 September 2026, quotations translated from Polish). A few weeks of sensor data buys anomaly detection; it does not buy failure prediction. We publish no percentages of our own, because we have nowhere to get them from — we publish what you can check yourself: that the page giving those figures gives no source.
The distinction itself already exists in Polish, incidentally: Signalo writes that “monitoring is not yet prediction”, and ASTOR does the same in a controls engineer’s language, working through a temperature chart (in its Poradnik Automatyka, 5 September 2023; both pages read on 8 September 2026, both quotations translated from Polish). One sentence is missing from both: condition monitoring needs no failure register, and prediction learned from your own machines does not exist without one. Hence the test to run on the offer itself — if nobody asks how many failures of a given type you have on record, that is an offer for a data-collection project priced as a prediction project; we write about that under AI in manufacturing.
Four possible outcomes, and the first project for each
The test ends in one of four places, and each has a different first project — and a different thing not worth buying this quarter.
| Register and signals, joined | Register but no signals | Signals but no register | Neither one nor the other | |
|---|---|---|---|---|
| First project | a pilot on one machine class and one failure mode, if question five returns enough events of it | the cost of that machine’s failures, then a decision on instrumentation | a failure register, and anomaly detection on the signals already archived | a failure register and an assistant over the documentation |
| What can honestly be promised | a warning for one failure mode, at a stated lead time | a basis for an investment decision, not a forecast | a signal that a machine is behaving unlike usual — with no name for the fault | a shorter path to root cause, and a history for the future |
| What not to buy this quarter | an extension across the rest of the machine fleet | sensors, before the cost of failure has been counted | a predictive model — there are no labels for it to learn from | a model — there is nothing to train it on |
A decision table, not a quotation. It deliberately carries no costs.
The register and the signals exist, and can be joined
This column assumes question five came back with a count worth learning from. Where the join works but the chosen failure mode has only a handful of events on record, the plant does not belong here yet: it takes the same route as a plant with signals and no register — the register keeps collecting events of that mode, it is worth checking meanwhile whether anomaly detection on the signals already archived gives the technicians anything, and question five comes round again on a review date set today.
The first decision concerns not the model but the machine. ISO 17359:2018 recommends in §7.2 a criticality assessment of all machines — against nine factors, among them the cost of downtime, the frequency of failure and the effect on safety — so that a list emerges of the machines covered by monitoring “(or not)”, meaning deliberately excluded as well. That parenthesis is the most useful thing in the whole standard: excluding a machine is a normal result of the analysis, not a defeat.
The second decision concerns the failure mode and follows the same order — §7.3 recommends an FMEA or FMECA, so that the expected faults and their symptoms are identified first and the parameters worth measuring only afterwards. Signalo condenses this into one sentence: “failure mode first, then sensor” (read on 8 September 2026, quotation translated from Polish).
The scope of a first AI project — with us and with any other supplier — is set out under AI implementation for business, and the division into phases under our implementation methodology. Five questions for the supplier who will run that pilot:
- Which failure mode is the model to predict? The answer “failures” is not an answer.
- How many events of that mode are in our register — and have you seen that export?
- How much warning should it give? The time between detecting a fault and the failure is what ISO 17359:2018 calls, in §8.5, the lead time to failure, noting that it particularly affects the frequency of measurement and the type of monitoring system.
- Supervised method or unsupervised? Which is to say: failure prediction, or anomaly detection.
- What happens to the model in its second year? Microsoft itself raises this: were the model perfect, it would remove failure events from the population — and since a supervised method learns from exactly those, retraining such a solution makes the model worse.
In the same guide, the model’s output either raises a maintenance work order or reaches an expert — a human in the loop — who decides where to direct limited resources. Which of those two routes applies at your plant is a decision to take before the pilot, not after it.
There is a register but no signals
The decision is this: work out what this machine’s failures cost, before anyone selects a sensor. ISO 17359:2018 places, in §5, a feasibility and benefit analysis ahead of choosing a monitoring method, and lists for consideration the life-cycle cost, the cost of lost production, secondary damage, and warranty and insurance. Those four items, counted for one machine, mean more than any presentation.
The cost on the other side can be named without quoting a range: the number of machines to be instrumented; whether archiving can be configured in the existing controllers and SCADA or has to be built from nothing; and whether the plant has a CMMS at all. Until those three are settled, the number in an offer is not a quotation — we set out how the costs break down in the piece on what an AI implementation costs.
The signals exist but the register does not
This outcome looks the most promising and is the easiest to overrate. An archive of measurements without a failure register yields no labels, and without labels there is no supervised learning — which is to say, no failure prediction learned from these machines. What it does yield is what an archive of signals always yields: anomaly detection, described above, learns from the signals alone.
So the first project is a double one. The register — the same one whose fields are listed below — starts collecting labels from tomorrow. In parallel it is worth checking whether anomaly detection, running on the signals you already archive, gives the technicians anything useful; wherever signals are archived, that is the one thing that works without waiting for a history. You come back to question five with a count of events instead of a guess — when the new register holds events of that failure mode to count, or on a review date set today, whichever comes first.
Neither the register nor the signals
This is the most common answer and the least dramatic, because it yields a project that is feasible from tomorrow. The register worth setting up has seven fields:
- machine identifier — the same one the controls engineer uses, not a separate one;
- moment of occurrence and moment of resolution — two columns, both with a time;
- symptom observed — from a list, not from the keyboard;
- cause found — also from a list, extended after the first quarter;
- part replaced;
- downtime.
A list drawn up from ISO 17359:2018 §8.7 (the minimum content of a record of monitored parameters) — not a quotation from the standard. Standard read on 8 September 2026. The failure report form itself is nothing new in the Polish literature; what is new is what it is filled in for — every one of those fields is a column a model will one day be trained on.
The other half of that project is described under AI implementations in a manufacturing business: an assistant over the equipment documentation and the repair history. It works in both directions — a technician who gets a sensible answer is more inclined to close a ticket with a description than with the word “fixed”, and that description is exactly the content the register lacks.
When predictive maintenance is not your first problem
The most common honest answer to the question in the title is “not yet” — and it is better heard from somebody who then has nothing to sell you instead.
- The failure mode gives no measurable symptom. ISO 17359:2018 says plainly in §7.4 that another strategy may then be needed — burn-in, run-to-failure, corrective or preventive maintenance, or redesign. In the standard, running to failure is a strategy, not negligence.
- Prevention does not work. Where inspections are disorderly the data is disorderly too, so what the model gets from it is noise rather than a pattern — that is ASTOR’s thesis, cited at the top.
- The machine is one of a kind and rarely fails. It sounds like bad news and is good news: the money that would have gone on a model stays available for spare parts and an inspection.
- Nobody will take the decision a warning implies. Even once a fault has been detected, estimating the time to failure calls for expert judgement or empirical methods (NISTIR 8012 from 2014). Without a person who will stop the machine and take responsibility for doing so, a model produces notifications rather than decisions.
Prediction with no data history is on our list of the things we do not do. This post describes how to arrive at that refusal on your own — before anybody invoices you for it.
What to do this afternoon
- Pick one class of identical machines, or one machine if no such class exists. Not the most expensive one, but the one about which somebody can name from memory a failure mode that keeps coming back.
- Order two exports covering the same twelve months: the tickets for the machines you picked from the maintenance manager, and their signal history from the controls engineer or the SCADA supplier — at machine level, not line level, with the machine identifier against every event and every measurement.
- Open both files side by side and check two things: whether the identifier from the first appears in the second in the same form, and how many times that one failure mode occurred.
Then you know — from the files, not from assurances — which column of the outcome table your plant stands in. If you would like somebody to go through those two files with you, we do that — including when the answer turns out to be “not worth it yet”. That is a result too, and a cheaper one than reaching the same conclusion after buying sensors.