An End-to-End Predictive Maintenance Pipeline
A containerized FastAPI and Streamlit system for equipment-failure prediction, failure-type classification, model comparison, and monitoring reports.
- Python
- scikit-learn
- FastAPI
- Streamlit
- Docker
- GitHub Actions
Connects preprocessing, model training, serialized artifacts, API inference, reporting, and a Streamlit interface in one repository rather than stopping at a notebook.
Contents
The Problem
Predictive maintenance has two connected questions: will equipment fail, and if so, what kind of failure is likely? A useful prototype must carry those predictions beyond a notebook into reproducible artifacts and an interface.
Why This Approach?
The repository compares classical classifiers before serving selected models. This is appropriate for structured process variables such as temperatures, rotational speed, torque, and tool wear, where tree models and linear baselines remain strong, inspectable choices.
Architecture
The project separates data processing, exploratory analysis, training, metrics, prediction, and report generation. Serialized models and a scaler feed a FastAPI backend; Streamlit provides prediction, EDA, monitoring, and performance pages. Docker Compose coordinates the services.
Implementation
The repository contains raw and processed data, configuration, model artifacts, metric snapshots, generated HTML reports, backend and frontend Dockerfiles, and a GitHub Actions workflow. That structure makes the data-to-interface path visible, though committed artifacts also increase repository size and require careful provenance management.
Experiments and Results
The committed metric snapshots compare Logistic Regression, SVC, Decision Tree, and Random Forest for binary failure prediction and multi-class failure-type classification. They report Random Forest accuracy near 99.2% for both tasks on a 9,266-row evaluation set.
These numbers are repository evidence, not independently rerun results. The site does not translate them into operational downtime savings, and the unusually high scores warrant leakage and split-strategy checks before broader interpretation.
What Failed?
The repository has no visible automated test suite. Its README claims deployment, but the current availability and production usage were not verified. Committing models, processed data, reports, and notebook outputs makes lineage harder to audit unless every artifact is tied to code, input hashes, and a split definition.
What I Learned
The project demonstrates the engineering distance between model training and a usable ML system. It also shows why strong headline metrics should trigger more provenance questions, not fewer.
Next Steps
- Add unit tests and an inference contract test between API and model artifacts.
- Record dataset hashes, split logic, feature schema, and training revision with every model.
- Add temporal or group-aware validation if the data-generation process requires it.
- Replace static monitoring reports with drift checks against a stored baseline.