From predictive maintenance 4.0 to 5.0: bringing humans back into the loop with a self-learning platform and implementation roadmap on automated production lines Open Access

Industry 4.0 (I4.0) has transformed manufacturing through digitalisation, automation and data-driven decision-making (Lucantoni et al., 2025a, b). Building on this shift, Industry 5.0 (I5.0) introduces a human-centric perspective that emphasises collaboration between humans and intelligent systems, skills development and responsible use of technology (Rame et al., 2024).

The increased complexity of production systems under I4.0 fostered the diffusion of preventive and predictive maintenance (PdM), supported by advanced monitoring and analytics (Antomarioni et al., 2023; Ding and Kamaruddin, 2015; Skoumpopoulou et al., 2025). Artificial Intelligence (AI) and Machine learning (ML) now play a central role, enabling more accurate failure prediction and improved equipment performance (Xu et al., 2023).

However, designing PdM solutions that are both accurate and deployable in real industrial IoT environments is challenging (De Luca et al., 2023; Nunes et al., 2023). Practitioners still lack concrete guidance on how to integrate AI-based PdM into day-to-day processes in a human-centric perspective. Existing platforms typically emphasise algorithmic performance and rarely combine (Pal, 2024; Yang et al., 2022): (1) self-learning capabilities, (2) explicit human–machine collaboration mechanisms and (3) structured implementation roadmaps. Recent contributions on Maintenance 5.0 also show that, although interest in the topic is increasing across countries, collaboration between researchers and organisations remains weak (Aktef et al., 2026), highlighting the need for new maintenance frameworks co-designed and validated in real industrial settings.

Taken together, these challenges indicate that there is still no clear, actionable pathway from PdM 4.0 to PdM 5.0 that jointly operationalises AI/ML models, human-centred interaction and practitioner-oriented guidance within a single operational framework.

Against this background, the purpose of this paper is to design, implement and empirically validate a PdM 5.0 platform for automated production lines, explicitly aligned with I5.0 principles and with the emerging needs of operations management. The contribution is threefold:

1. Conceptual: articulating a PdM 5.0 perspective that integrates I4.0 technologies with I5.0 human-centric requirements, framing PdM as a human–AI collaborative decision process.

2. Technological: proposing an AI-driven, self-learning platform combining ML-based predictions, probabilistic and explainable insights and human–machine collaboration features.

3. Managerial: developing an implementation roadmap for PdM 5.0 and implementation and validation on three fully automated automotive assembly lines.

The reminder of the paper is organised as follows: Section 2 presents the literature review; Section 3 describes the platform framework and its components; Section 4 reports the industrial application and validation of the platform; discussion and conclusions are in Sections 5 and 6, respectively.

The literature review first identified conceptual and technological challenges for HMC in I5.0, then analysing how current PdM 5.0 and 4.0 applications address these challenges.

To identify key challenges from an I5.0 perspective, a Scopus search on human–computer/machine interaction and I5.0 was conducted identifying seven review papers (Table 1) that explicitly discuss HMC requirements, allowing to distil cross-cutting issues rather than technology-specific problems Overall, these reviews converge on the need for AI-based support in dynamic work environments, adaptive and transparent algorithms, and careful attention to user experience and portability across devices and contexts.

Empirical PdM applications explicitly framed within I5.0 and HMC are still limited. A Scopus query (“predictive maintenance” OR “PdM”) AND (“Human-Computer Interaction” OR “HMC” OR “human-machine interaction”) AND (“case-stud*” OR “case stud*” OR “application*”) AND (“Industry 5.0” OR “I5.0”) returned only two applications: Hamdani and Chihi (2025) and Ahdi et al. (2024). The former focuses on fault detection and diagnosis rather than failure prediction; the latter, together with Quandt et al. (2022), discusses human-centred technologies in I5.0 but does not propose a complete PdM platform aligned with the challenges.

To broaden the analysis beyond systems explicitly labelled as HMC, the HMC-related terms were removed from the string, enabling a wider exploration of PdM methodologies within I5.0. Digital Twins (Abolghasem et al., 2025; Daraba et al., 2024; Kovari, 2025) emerge as key enablers, allowing real-time monitoring and simulation of physical assets and supporting predictive analytics and failure forecasting. Generative-AI chatbots (Kiangala and Wang, 2024) collect real-time information from operators on equipment conditions and improve communication and visualisation but are not integrated with ML modules not providing complete PdM platforms. Ahmed Murtaza et al. (2024) propose a conceptual framework for transitioning PdM from I4.0 to I5.0, without numerical validation, interface description or usability assessment. IIoT-based platforms (Aragonés et al., 2024) are increasingly used for PdM (e.g. vibration monitoring) often relying on threshold-based logic or limited analytics, without embedding full PdM functionalities or real-time OEE assessment, leading to weak user engagement and adaptability (Lucantoni et al., 2025a). A dedicated Scopus search with (“predictive maintenance” OR “PdM”) AND (“Human machine” OR “Human-computer”) AND (“roadmap”) not identified studies presenting implementation roadmaps, suggesting that implementation pathways are rarely documented.

To complement the I5.0-oriented perspective, PdM 4.0 platforms are investigated. ML in PdM has evolved along three main development paths: (1) task-centred, applying algorithms to specific tasks such as fault detection and process optimisation (Gobert et al., 2018; Lucantoni et al., 2023); (2) technology-centred, integrating ML with enabling technologies such as monitoring systems and image recognition (Abellan-Nebot and Romero Subirón, 2010; Caggiano et al., 2019; Yun et al., 2023); and (3) industry-centred, addressing real-world industrial applications and constraints (Sharma et al., 2021; Yang et al., 2022).

Viewed through an I5.0 lens, several limitations emerge. Few studies provide interpretability or transparency in decision-making, limiting trust in AI predictions (Wu et al., 2022). RNN–LSTM models are widely adopted for sequential data and are attractive for their practical implementation (Sherstinsky, 2021), while hybrid solutions such as KNN–LSTM can achieve high accuracy but suffer from higher training costs and unstable performance on large datasets (Nguyen et al., 2023).

In the reviewed frameworks and applications, PdM performance is mainly assessed through reliability-oriented indicators such as Mean Time to Repair (MTTR) and Mean Time between Failures (MTBF) (Liu et al., 2022; Ruschel et al., 2020; Yu et al., 2018). Although OEE is widely used in industrial practice, it is explicitly embedded into the PdM platform only in a minority of works; among the applications in Table 2, in fact, only Mohan et al. (2023) jointly consider the Remaining Useful Life (RUL) and OEE. As a consequence, the link between PdM decisions and system-level production performance is often left to separate tools or managerial interpretation. Moreover, many platforms do not systematically incorporate human expertise and feedback and thus fall short of HMC principles central to I5.0.

To the best of the authors' knowledge, the literature still lacks contributions that clearly explain, both theoretically and practically, how to transition from PdM 4.0 to PdM 5.0, supported by a structured implementation roadmap. Existing PdM 4.0 platforms typically focus on binary detection or point predictions and seldom provide probability estimates, confidence measures or prescriptive recommendations; moreover, they offer limited support for human–machine collaboration, with non-intuitive interfaces and scarce mechanisms for real-time operator feedback. As a result, although interest in Maintenance/PdM 5.0 is growing, many frameworks remain conceptual or lab-based and are not co-designed and validated in real automated settings. Taken together, these gaps indicate that there is still no clear, actionable pathway from PdM 4.0 to PdM 5.0 that jointly operationalises AI/ML models, human-centred interaction and practitioner-oriented guidance within a single framework. This paper addresses these gaps through the proposed PdM 5.0 platform and its implementation roadmap.

This section presents the methodological basis of the proposed PdM 5.0 solution. Section 3.1 describes the overall PdM 5.0 framework, including its main modules and the human roles involved. Section 3.2 introduces the implementation roadmap, i.e. how the framework can be deployed and evolved in companies with automated or semi-automated production lines.

The PdM 5.0 framework (Figure 1) is structured as a modular socio-technical system. It consists of seven technical modules, i.e. (1) Industrial Data Acquisition, (2) Data Analytics and Management, (3) PdM 5.0 Engine, (4) Collaborative Decision Support, (5) Augmented Alert and Human Action, (6) Engine Management, and a cross-cutting (7) Human Expertise and Collaboration Hub.

These modules are interconnected through three main flows: (1) an automated data and information flow from field devices to analytics and KPIs; (2) a human-centric engagement and control flow, enabling operators and managers to interact with predictions and KPIs; and (3) a human-in-the-loop AI refinement flow, in which user feedback contributes to model and interface improvement. Human roles are mapped onto this architecture (Table 3) and are detailed, together with each module, in the following subsections.

These foundational modules collect, process and manage the data used by the PdM 5.0 platform. Data are acquired from IoT devices, sensors, PLCs and maintenance reports, under the responsibility of the IoT Engineer. Where needed, integration with Product Lifecycle Management (PLM)/Enterprise Resource Planning (ERP) systems is ensured via Application Programming Interface (API).

Raw data are routed through a gateway to a cloud data centre for storage and processing. The Secure and Ethical Data Officer oversees privacy, integrity and compliant use of data. Feature engineering transforms raw signals into model-ready features by cleaning, filtering irrelevant or redundant information and ensuring consistency. This structured knowledge base supports multiple applications without conflicts.

Action Outcome Data, capturing verified maintenance results (e.g. actual failure mode, successful repair, time to failure), provide the ground truth for continuous learning and are continuously fed back into Module 3 for predictive analytics and decision support.

The PdM 5.0 Engine is the platform's intelligent core, providing diagnostic and predictive insights and addressing “why” failures occur and “what” is likely to happen. It processes the knowledge base produced by the data modules, detects operational deviations and generates timely alerts to prevent quality degradation or critical failures. A heuristic, iterative approach was adopted to guide the selection and tuning of the algorithms used in the ML module, ensuring coherence with the overall architecture presented in Figure 1. This procedure started from preliminary data exploration and candidate-model screening and proceeded through successive refinement cycles based on prediction performance, stability and interpretability.

Once the ML algorithm is selected, the initial dataset should be partitioned into training and testing subsets, with particular attention to extended downtimes to identify “stationary line” states as key events for model training. Once trained, the ML model processes live data to detect early signs of failure and estimates the probability of occurrence over multiple short-term horizons, supporting proactive decisions. For each alert, the engine also provides XAI insights (e.g. most influential variables), helping operators and managers interpret AI recommendations.

Self-learning is enabled by a Retraining Trigger that combines drift detection with human-in-the-loop refinement. Data and performance are continuously monitored, while feedback from maintainers and production managers, partly collected via the live chat and other interactions, is periodically reviewed by the ML Engineer to decide when and how to update the models. In this way, model evolution remains deliberate and grounded in validated input, while the engine shares real-time insights with Engine Management and CDS for coordinated decision-making.

The CDS module is the main interface for human–AI collaboration in maintenance decision-making. It integrates AI predictions on potential failures and performance deviations with XAI insights, displaying for each alert the estimated failure probability and the most influential variables. This explanation layer supports operator understanding and trust.

Operator input is explicitly embedded in the CDS workflow. Through the CDS panel, operators can confirm or override the suggested failure cause and add short notes on the event context (e.g. material shortage, sensor misalignment, set-up errors). These annotations are stored with the prediction and periodically reviewed by maintenance and process engineers to identify systematic model errors and to enrich the training set during retraining cycles, thus closing the self-learning loop.

A Collaborative Decision Facilitator coordinates this interaction, validates AI-driven recommendations and consolidates them into actionable maintenance plans. Validated actions are forwarded to Module 5 for execution. The CDS module also offers a simple drag-and-drop interface to view and adjust the weekly maintenance schedule and a real-time progress bar of completed tasks, linking predictive intelligence, human expertise and workload planning in a single environment.

This module translates predictive insights into concrete interventions. Once the PdM 5.0 Engine and CDS have generated actionable recommendations, Augmented Alert and Human Action delivers immediate alerts to maintenance personnel through an intuitive traffic-light system:

1. Green: normal operation, no immediate risk.

2. Yellow: warning, a potential failure is approaching and requires attention.

3. Red: alarm, an imminent failure is expected and requires immediate action.

4. Block/neutral state: system failure or complete stoppage.

Maintenance workers receive the alert with associated recommendations, validate the proposed actions and execute them directly on the line. If issues arise, they can request support or clarification via the live chat. Once the intervention is completed, maintenance reports and outcomes are logged and stored as Action Outcome Data, which feedback into the data and engine modules, maintaining the control loop and supporting continuous learning.

The Engine Management module ensures the integration of PdM decisions within the broader maintenance and production system. Overseen mainly by the Production Manager, it supports the coordination of activities across different organisational levels (e.g. plant, section, functional location) and provides a consolidated view of operational data.

The module includes functionalities for regulatory compliance (such as the UNI 10584 Maintenance Information System standard), maintenance monitoring and management (routine, extraordinary, preventive and predictive), enabling continuous tracking of interventions and related performance metrics. It receives insights and predictions from Module 3 (PdM5.0 engine) and uses them to support planning and prioritisation of maintenance tasks. In turn, it provides strategic feedback to the ML and maintenance engineers, helping to align model tuning with evolving business objectives and constraints.

The Human Expertise and Collaboration Hub is the core of the platform's human-centric design, enabling real-time and remote interaction between human expertise and the AI system. It brings together operational know-how, analytical and engineering competences, and managerial oversight, orchestrated through a usability feedback loop managed by the User Support and Training Coordinator. The hub provides a web-based environment with:

1. Adaptive user interfaces, which visualise CDS outputs and alerts through configurable dashboards (including traffic-light views);

2. KPI visualisation, offering real-time monitoring of equipment health and the effectiveness of PdM decisions;

3. Multi-devices and external services, enabling users to connect from different devices and generate reports for managers;

4. A live chat interface, supporting issue reporting, clarification requests, XAI explanations and communication among human actors and with the ML Engineer.

User training and usability feedback are systematically collected and used by the HMI Manager and other roles to refine interfaces and interaction modes. In this way, the hub ensures that the platform evolves not only from a technical standpoint but also from a human–machine collaboration perspective.

The roadmap in Figure 2 illustrates how the self-learning PdM 5.0 platform can be implemented in practice, moving from initial concept to full deployment. It is based on a 30-month transformation path, particularly suited for organisations transitioning from traditional preventive maintenance to AI-supported, more autonomous PdM.

The roadmap is structured along three dimensions, following Pizoń and Gola (2023(data integrity, security and system autonomy), Social (human collaboration, feedback and communication with machines) and Technical (platform development, testing and optimisation). These dimensions are visually distinguished in and help balance human, organisational and technological aspects throughout the platform implementation.

Regular training sessions support this evolution: an initial kick-off session aligns the team on objectives and methods; subsequent training (basic, upgrade and advanced) progressively deepens users' familiarity with the platform, from basic navigation and data interpretation to responding to real scenarios. A final session focuses on supervising a more autonomous system and intervening in exceptional cases.

Overall, the roadmap can be read as a generic sequence of assessment, design, implementation, validation and continuous improvement. Its applicability is scoped to contexts with automated or semi-automated production lines, where sufficient sensing and data infrastructure already exist. In predominantly manual environments, preliminary investments in basic automation and data collection would be required before adopting a similar sequence. Within automated settings, individual steps and tools can be adapted while preserving the overall logic of the roadmap.

This section describes development, implementation and validation of the PdM 5.0 platform on a fully automated assembly context.

The first year of the roadmap was dedicated to the development of the self-learning platform. This phase covered both hardware and software aspects: real-time data collection from machines and PLCs, and progressive configuration of the platform modules.

The HMC-based self-learning platform was implemented in a well-known Italian automotive company during its transition from preventive to predictive maintenance. In the first two months, the most critical production line in terms of failure occurrence and management effort was identified. A fully automated pump assembly line was therefore selected as pilot. The line operates 24/7 and consists of twelve workstations (WSs). WS1 manages manual loading and initial quality checks; the following WSs comprise multiple automatic stations (STs) performing sensor-based inspections, component insertion and calibration, supported by conveyor and pallet handling systems. WS12 performs final tests and additional quality checks. Once the architecture was validated on this line, it was extended to three automated lines, for a total of 30 WSs and 160 STs configured in the platform.

During the first twelve months, the KPIs were defined (Section 4.3 for details) and iteratively refined to assess platform performance and maintenance effectiveness. Targets refer to the last six months of full application. Usability tests were also planned to evaluate the impact of HMC features on task execution and user experience (results in Section 4.3). For each ST, a subset of ten process variables was selected from PLC signals, together with maintenance and process engineers, according to three criteria: (1) direct linkage to known failure modes, (2) data quality and availability in logs, and (3) avoidance of strong multicollinearity. The final set, used both for KPI calculation and PdM modelling, includes: machine status, failure codes, counts, rejects, cycle time, energy consumption and derived indicators such as downtime duration, operating time, production rates and good pieces.

Several ML approaches were empirically tested before converging on the final solution. Initial rule-based and association-rule models, fed by manually collected data, achieved only moderate accuracy and negligible OEE gains, mainly due to data quality and consistency issues. A subsequent approach based on sequential pattern mining also proved difficult to scale, given heterogeneous stations and very short cycle times. These limitations motivated the adoption of LSTM networks on real-time PLC data within the PdM 5.0 Engine (Module 3), which offered the best trade-off between prediction performance, robustness and computational effort. Its implementation followed four steps:

1. Data collection and preprocessing. Real-time PLC data were organised into multivariate time-series windows. A preliminary analysis of downtimes over four weeks identified the most frequent and long-lasting failure codes. In the maintenance information system, each downtime is tagged with a numeric code; codes 170 and 128, occurring in WS10-ST4 and WS5-ST1, respectively (i.e. “punching problem” and “robot clampind error”), emerged as particularly critical. However, recognising the importance of all identified failures, the decision was to examine the entire production line comprehensively. Failures distributions in terms of duration and frequency were thus analysed, together with occasional interruptions of the monitoring system, which generated temporary gaps in the dataset. As new data accumulated, these gaps became less relevant and data quality progressively improved. Prototyping tools (e.g. Jupyter Notebook) were used to explore the MongoDB dataset and refine preprocessing choices.

2. Model training. The LSTM model was trained on time windows representing the recent behaviour of the line. An initial threshold of 5 min was used to define “stationary line” states for labelling; about 200 significant stoppages were selected to build the first training set. The dataset was randomly split into training and test subsets to avoid bias. Different values of downtime interval and prediction horizon were tested to identify the configuration that maximised early-warning capability while limiting false positives.

3. Predictive analysis. Once deployed, the model continuously processes incoming data. Every few seconds, the current time window is compared with the trained model, and the system estimates failure probabilities over short horizons (e.g. 6 and 3 min). When a warning or alarm is issued, the dashboard communicates severity, while the XAI layer highlights the main contributing variables (e.g. abnormal machine status and high consecutive rejects), helping operators to understand the alert and act accordingly.

4. Human input and feedback. Model outputs and KPIs are aggregated into SQL tables and visualised through dashboards accessible on tablets, PCs and smartphones within the Human Expertise and Collaboration Hub. Operators can confirm or correct alerts and add short notes on the event context. In one representative case, the model signalled an imminent failure (code 170) with high probability, driven by abnormal cycle time and consecutive rejects at WK4-ST2. The operator confirmed the alert, noted a progressive misalignment of the crimping unit and performed a quick adjustment, avoiding an estimated 30-min line stop. Such episodes, together with usability feedback, were later used to refine the training set and tune thresholds. The high scores for “Result Clarity” and “Task Comprehensibility” in Table 5 reflect this combined effect of XAI explanations and structured operator input.

The experimentation phase involved iterative testing of the ML system in real operating conditions. A prototype-based optimisation logic was adopted: each platform release was used on the line, evaluated and refined based on change requests and improvement ideas. Alongside minor bug fixes, major updates focused on KPI visualisation, traffic-light-based maintenance forecasts, integration with existing information systems and progressive enhancement of XAI and chatbot functionalities in response to operator feedback.

A new interface for maintenance forecasts, based on the traffic-light system was introduced to communicate predictions intuitively (Figure 3). Dashboards were designed to display KPIs at line, workstation and station level, accessible from multiple devices and printable as daily, weekly, monthly or quarterly reports. In parallel, integration with the factory Outlook system enabled automatic retrieval of test data and computation of ppk indices, providing managers with an overview of test trends for different products.

The PdM 5.0 platform was ultimately implemented on three production lines, with 30 WSs and 160 STs configured and approximately ten parameters per ST fed into the pipeline. Qualitative and quantitative results are reported in Table 4 and 5 respectively.

Prediction performance proved robust, with approximately 83% effectiveness within six minutes before a downtime event and over 75% within three minutes. Overall, the implementation resulted in an average OEE improvement of 19.65% across the monitored lines. In brief:

1. Line 1 increased its product mix from one to three product types, introducing two product changes per month. This added around 24 h of downtime and reduced OEE by about 4.5%, partially offsetting the gains from the PdM system.

2. Line 2, initially affected by start-up conditions, showed a more realistic baseline OEE of around 45%. The platform enabled an OEE increase of 16.6%, with a benefit–cost ratio of 1.45.

3. Line 3 experienced an OEE reduction of approximately 3% for each new product family introduced, reflecting the impact of complexity on performance.

From a usability perspective, Table 5 indicates a generally positive perception of the framework. All tasks were completed without errors, with limited need for assistance. Average scores for task comprehensibility, satisfaction and result clarity are high, while perceived task complexity is low. This suggests that operators were able to appropriate the platform and integrate it into their routines. Lower scores in “Platform organisation” and in the visualisation of algorithm outputs highlight areas for improvement, such as simplifying navigation and further clarifying the meaning of predictive alerts.

This section discusses the main implications of the HMC-based self-learning PdM platform, linking the findings to the literature. The discussion is structured around (1) theoretical contributions to PdM 5.0 and HMC research, and (2) practical/managerial implications for automated production lines and for the transition from PdM 4.0 to PdM 5.0.

The proposed framework addresses the gaps summarised in Section 2.2 by providing an integrated PdM–HMC architecture and implementation roadmap that jointly considers AI/ML models, human–machine collaboration mechanisms, and KPI-oriented decision support. It thus offers a concrete pathway from data-centric PdM 4.0 solutions to PdM 5.0, where prediction is embedded in accountable, human-centred decision-making.

Second, the framework operationalises self-learning and human-in-the-loop concepts discussed in recent I5.0 and HMC literature. Drift detection, conditional retraining, and structured operator feedback are integrated into a single learning loop that continuously adapts the PdM engine while preserving human oversight. This reframes PdM as a human–AI collaborative decision process rather than a purely technical forecasting task. The framework is model-agnostic: while LSTM networks were used in this study, the modular ML layer can be replaced by alternative algorithms depending on data characteristics and operational constraints.

Third, the framework shows how HMC requirements highlighted in prior reviews (e.g. collaboration technologies, portability, workforce skills, and firm-oriented solutions) can be instantiated in a concrete platform and validated in an industrial setting. Table 6 maps the platform's capabilities to I4.0/I5.0 and HMC requirements (Tables 1 and 2), highlighting a coherent socio-technical system combining probabilistic reasoning and XAI, collaboration and feedback features, KPI visualisation, edge-enabled data management, and dedicated organisational roles.

Beyond the methodological contribution, the case study clarifies how a PdM 5.0 solution can be operationalised on automated lines and which value levers it activates, addressing recurring issues such as fragmented initiatives, weak links between PdM outputs and production performance, low trust in black-box models, and lack of an adoption pathway. Implemented on three fully automated assembly lines in an Italian automotive plant, the platform supported the transition from preventive and early PdM 4.0 practices to an integrated PdM 5.0 approach, enabling short-horizon probabilistic forecasts (3–6 min) and traffic-light alerts associated with reduced downtime and scrap and improved OEE.

Operationally, probabilistic forecasts are translated into decision-ready shop-floor signals and KPI-oriented dashboards, reducing the prediction-to-action gap. Drift detection and conditional retraining mitigate model degradation, while edge-enabled data management supports near-real-time monitoring in heterogeneous, legacy-constrained environments. Organisationally, automated reporting and structured feedback channels reduced diagnostic effort and shifted operators from manual inspection toward evaluation and refinement of AI-supported recommendations supporting trust, engagement and digital skill development; dedicated roles further strengthen governance (monitoring, escalation and retraining approvals).

Economically, OEE improvements derive from avoided downtime and scrap, higher throughput, and shorter decision times, delivering productivity gains while reducing operational waste. These benefits can be assessed through a cost–benefit analysis that weighs avoided losses and efficiency gains against the costs of integration, platform setup, training, and ongoing governance.

This business-oriented framing also supports transferability: the roadmap provides a non-prescriptive adoption sequence adaptable to company size and digital maturity, while the modular architecture can be transferred beyond automotive provided that machine states/events and maintenance outcomes are observable.

This paper presented a self-learning PdM 5.0 platform integrating AI-based prediction, human–machine collaboration, and KPI-oriented decision support within a unified architecture and implementation roadmap. The main contribution lies less in the specific ML implementation than in a deployable, model-agnostic socio-technical framework that operationalises PdM 5.0 principles. The study provides in fact a first operational step toward harmonising AI-driven predictive capabilities with human-centric, explainable, and sustainable decision-making frameworks by coupling decision-ready probabilistic alerts, inspectable explanations, a human-governed self-learning loop, and KPI-anchored decision support that makes trade-offs explicit and can support more resource-efficient operations through reduced scrap and unplanned stops. In this study, sustainable decision-making is also addressed as sustained, governable and trustworthy use of PdM over time (trust, traceability and controlled change).

The framework also bridged the gap between academic research and practical implementation of 5.0 initiatives: validated through a longitudinal intervention on three automated assembly lines in an Italian automotive plant, the platform connected short-horizon probabilistic forecasts (3–6 min) to interpretable alerts and workflow-integrated recommendations, contributing to reduced unplanned downtime and scrap and to an average OEE improvement of about 20%, with positive usability evidence suggesting that operators could trust and appropriate the platform within routine decision-making.

The architecture is transferable beyond the automotive case, with effectiveness depending on data observability, event logging, and automation level. Limitations include the single-case setting and the use of one family of ML models; future research should test other sectors, maturity levels, and algorithms, assessing longer-term organisational and behavioural impacts, and integrate explicit sustainability-oriented indicators into KPI dashboard and decision policies.

During the preparation of this work the authors used generative AI in order to improve readability and language. After using this service, the authors reviewed and edited the content as needed and take full responsibility for the content of the publication.