Bearing Fault Copilot

Unplanned bearing failures stop production, and a maintenance technician often has a vibration trace but no quick way to turn it into an action. Bearing Fault Copilot closes that gap in four steps. 1. Detect: a random-forest classifier reads a window of vibration data from the CWRU bearing dataset and predicts the fault type, severity and confidence. A separate physics check looks for peaks at the characteristic fault frequencies and is shown next to the result. 2. Retrieve: the result becomes a hybrid keyword and embedding search over our maintenance knowledge base (team-written reference notes, a curated fault-to-action table and synthetic maintenance logs). 3. Explain: an LLM, DeepSeek-V4-Flash-Vision-Exp served through AMD Token Factory on AMD GPUs, writes the explanation, likely causes and recommended actions, each tied to a cited passage. 4. Act: a person must confirm or escalate before any safety-critical step is accepted. Trust is built into the design. The model writes only the text. The sensor result, uncertainty, citations and confirm flags are filled in by code, invented citations are dropped, and steps that involve stopping, isolating or opening the machine are flagged safety-critical by code even if the model misses them. When the classifier is unsure, the answer says so and puts manual inspection first. If the LLM is unavailable, the app still returns the sensor result and citations. Honest limits: accuracy is 0.990 on a motor load the model has not seen, but drops to between 0.50 and 1.00 on unseen fault sizes. The data comes from a lab rig, not a factory, and retrieval was tested on our own questions.