A maintenance prediction needs time to act

Research design perspective | Logic Foundry | October 12, 2026. This article proposes a way to discuss predictive maintenance with operators, equipment providers and technical partners. All examples are fictional. No model performance, completed trial or customer outcome is claimed.

1. Start with the decision, then the prediction

Imagine a fictional building team receiving a warning about a component shortly before an expected problem. Even if the warning later proves correct, the team may have had no practical opportunity to arrange access, obtain a replacement or seek specialist advice. A useful design discussion should therefore ask what decision the warning is meant to enable.

Choose a bounded decision for the discussion: whether to request an inspection, reserve a replacement part or plan an authorised service visit. These are different decisions with different evidence needs. A prediction that might justify looking more closely does not automatically justify replacing equipment.

Our proposal is to write that decision in ordinary language before discussing model selection. Identify who can make it, what information they need and what would happen if the warning never arrived. Existing maintenance requirements and escalation procedures remain the starting point.

2. Work backward from the action

For the fictional service visit, list the steps between receiving a warning and performing the authorised work. The sequence might include reviewing the evidence, confirming the asset, consulting a specialist, arranging access and checking material availability. Ask the responsible people which steps are genuinely required rather than assuming a generic lead time.

Record uncertainty in the plan. A part that is normally stocked may not be available in the relevant period. An expected access window may still need agreement. The purpose of the exercise is to describe what the team could realistically do with advance notice, not to turn estimates into commitments.

Then ask what warning horizon would make the selected decision meaningfully different. A short warning may support one response while a longer warning could enable another. Do not prescribe a universal interval across asset types, buildings or operating conditions. Define the intended use for each proposed evaluation.

3. Explain what the warning claims

A proposed interface should make the prediction understandable enough to question. Is it estimating that a defined event may occur within a period, suggesting an inspection, or flagging a change from an expected pattern? These statements should not be treated as interchangeable.

Keep the event definition explicit. In a fictional example, an unplanned service interruption, an observed defect and a scheduled component replacement would be recorded separately. A replacement decision is not, by itself, proof that an impending failure was correctly predicted.

Ask what evidence a reviewer could inspect alongside the warning: the asset identity, relevant observations, their timing and known missing information. If the proposed output includes a probability or confidence label, the evaluation should establish what that label means before people use it to prioritise work. This article supplies no validated threshold.

4. Plan for an incorrect or late warning

Consider a warning that prompts an inspection but reveals no actionable issue. Record what the response consumed and what the reviewer learned. Do not automatically call every unconfirmed warning useless: the investigation may be inconclusive. Keep confirmed findings, unresolved cases and rejected interpretations distinct.

Now consider an event that occurs without a useful warning. Ask whether the data were available, whether the event matched the intended scope and whether the team had time to act. Preserve the original information available at the decision point rather than explaining the case only with hindsight.

Repeated warnings need a plan too. In the proposed review, determine whether a new alert adds evidence, changes the requested action or merely repeats an unresolved message. A growing alert count should not be mistaken for a growing number of distinct equipment problems.

5. Try a tabletop exercise before an operational trial

Readers could select a small, non-sensitive set of historical maintenance cases and remove identifying details. Have someone familiar with the records prepare a timeline for each case, clearly marking what was known at each stage and what was discovered later. Include incomplete records rather than silently treating them as complete.

At several points in each timeline, ask an operator what decision they could have made with the information then available. Add a clearly labelled hypothetical warning and ask whether it changes the decision. This is an exercise in decision design; the invented warning is not a model prediction and must not be scored as one.

Record the evidence requested, time needed to respond, authority required and reasons the warning would not help. Include a case with a misleading warning and a case with no useful advance notice. The aim is to discover requirements and failure cases before proposing a live evaluation.

The hypothesis is that working backward from an action could expose gaps that a prediction-only demonstration would miss. The tabletop exercise can test whether the proposed workflow is understandable and feasible to discuss. It cannot establish predictive accuracy, avoided downtime, lower costs or a safe basis for changing maintenance intervals.

6. Define what a later evaluation would need

A future evaluation plan should distinguish model assessment from operational assessment. The former concerns the defined prediction and the evidence used to assess it. The latter concerns whether a responsible person could interpret the warning and take an appropriate action within the available time.

Keep the initial evaluation observational where appropriate, with decisions continuing through existing authorised procedures. Agree in advance how to record missing data, incorrect warnings, unanticipated events and changes in equipment configuration. A result that depends on excluding inconvenient cases should be examined rather than presented as a complete account.

Two discussion prompts can start a useful conversation with a technical partner: Which maintenance decision would advance notice actually change? What would your team need to see before acting on a warning that conflicts with its current understanding of the equipment?

CORE-FM currently supports properties, assets, work orders, preventive maintenance and sensor monitoring. Logic Foundry's confirmed research includes predictive maintenance, sensor anomaly detection and future decision tools. The framework above is a research design proposal, not a claim of a shipped prediction model, tested equipment integration or demonstrated reliability improvement.