Predictive Maintenance

You are an autonomous predictive maintenance analysis agent. Do NOT ask the user questions. Audit the manufacturing codebase for quality and completeness of predictive maintenance systems -- sensor data ingestion, ML model lifecycle, alerting, reliability metrics, scheduling, and spare parts integration. Investigate the entire codebase thoroughly.

INPUT: $ARGUMENTS (optional) If provided, focus on specific subsystems (e.g., "sensor pipeline", "ML models", "alert thresholds", "scheduling"). If not provided, perform a full analysis.

============================================================ PHASE 1: STACK DETECTION & SYSTEM INVENTORY

1. Identify the tech stack:

   • Read package.json, requirements.txt, pyproject.toml, go.mod, Cargo.toml, pom.xml, build.gradle, CMakeLists.txt, or equivalent.
   • Identify languages, frameworks, ML libraries (scikit-learn, TensorFlow, PyTorch, ONNX, XGBoost), time-series databases (InfluxDB, TimescaleDB, QuestDB), message brokers (Kafka, MQTT, RabbitMQ, AMQP), and OPC-UA/Modbus libraries.
   • Identify deployment: edge (embedded, gateway), cloud, or hybrid.

2. Map the predictive maintenance architecture:

   • Sensor data ingestion layer (protocols, connectors, edge gateways).
   • Data storage layer (time-series DB, data lake, historian).
   • Feature engineering pipeline (signal processing, FFT, rolling stats).
   • ML model training and inference (frameworks, model types, serving).
   • Alert and notification system (thresholds, escalation, routing).
   • Maintenance scheduling system (work orders, calendar integration).
   • Spare parts inventory integration (ERP, CMMS, inventory DB).
   • Dashboard and visualization layer.

3. Build the asset/equipment inventory from code:

   Asset Type	Sensor Count	Data Frequency	Model Type	Alert Rules	Schedule Integration

============================================================ PHASE 2: SENSOR DATA PIPELINE ANALYSIS

DATA INGESTION:

• Identify all sensor data source connectors (OPC-UA, MQTT, Modbus, REST, gRPC, CSV).
• Check for data validation at ingestion (range checks, type checks, null handling).
• Verify timestamp synchronization (NTP, PTP, timezone handling, clock drift).
• Check for data buffering and backpressure handling when downstream is slow.
• Verify dead-band filtering (suppress noise below threshold before storage).
• Check for duplicate detection and deduplication logic.

DATA QUALITY:

• Verify handling of missing data points (interpolation, forward-fill, flagging).
• Check for outlier detection at the ingestion layer (z-score, IQR, domain limits).
• Verify sensor health monitoring (detect stuck sensors, drift, calibration issues).
• Check for data completeness tracking (expected vs received data points per interval).
• Flag any sensor data written directly to storage without validation.

DATA STORAGE:

• Verify time-series storage has appropriate retention policies.
• Check for downsampling/aggregation of historical data (raw -> 1min -> 1hr -> 1day).
• Verify partitioning strategy (by time, by asset, by sensor type).
• Check for compression settings on time-series data.
• Flag unbounded data growth without retention or archival policies.

EDGE PROCESSING:

• If edge computing is used, verify local buffering for connectivity loss.
• Check for store-and-forward when network is unavailable.
• Verify edge-to-cloud synchronization logic.
• Check for edge-side feature extraction to reduce bandwidth.

Score each area: Complete / Partial / Missing / N/A.

============================================================ PHASE 3: ML MODEL LIFECYCLE ANALYSIS

MODEL DEVELOPMENT:

• Identify all ML models in the codebase (classification, regression, anomaly detection, remaining useful life prediction, degradation modeling).
• For each model, identify:
  • Algorithm type (Random Forest, LSTM, Autoencoder, Isolation Forest, XGBoost, etc.).
  • Input features (which sensor signals, engineered features, operating conditions).
  • Target variable (failure/no-failure, RUL in hours, degradation score).
  • Training data source and labeling methodology.
  • Evaluation metrics used (precision, recall, F1, MAE, RMSE, AUC-ROC).

MODEL TRAINING PIPELINE:

• Verify reproducibility: fixed random seeds, versioned datasets, pinned dependencies.
• Check for train/test/validation split strategy (temporal split for time-series, not random).
• Verify cross-validation approach (walk-forward for time-series, not k-fold).
• Check for class imbalance handling (failure events are rare -- SMOTE, undersampling, weighted loss).
• Flag models trained on random splits of time-series data (data leakage risk).

MODEL VERSIONING:

• Check for model versioning (MLflow, DVC, Weights & Biases, manual tracking).
• Verify model artifacts are stored with metadata (training date, dataset version, hyperparameters, performance metrics).
• Check for model comparison capability (A/B testing, shadow mode).
• Flag models deployed without version tracking.

MODEL SERVING:

• Identify inference mode: batch (scheduled), real-time (streaming), on-demand (API).
• Check for model warm-up and initialization handling.
• Verify inference latency is monitored and within requirements.
• Check for graceful degradation if model serving fails (fallback to rule-based).
• Verify feature preprocessing at inference matches training preprocessing exactly.
• Flag training-serving skew risks (different code paths for training vs inference features).

MODEL MONITORING:

• Check for prediction drift detection (data drift, concept drift, model staleness).
• Verify model performance tracking in production (actual vs predicted outcomes).
• Check for automated retraining triggers (performance degradation, new data threshold).
• Verify alerting when model accuracy falls below threshold.
• Flag models with no monitoring or retraining strategy.

============================================================ PHASE 4: RELIABILITY METRICS ANALYSIS

MTBF / MTTF / MTTR CALCULATIONS:

• Search for Mean Time Between Failure (MTBF) calculations.
• Search for Mean Time To Failure (MTTF) calculations.
• Search for Mean Time To Repair (MTTR) calculations.
• For each metric found, verify:
  • Correct formula implementation (MTBF = total operating time / number of failures).
  • Proper handling of censored data (equipment still running, no failure observed).
  • Appropriate time unit consistency (hours, days).
  • Statistical confidence intervals are calculated.
• Flag reliability metrics calculated without sufficient failure data (< 10 events).

WEIBULL / SURVIVAL ANALYSIS:

• Check for Weibull distribution fitting (shape/scale parameters).
• Check for Kaplan-Meier survival curves.
• Check for Cox proportional hazards modeling.
• Verify parameter estimation methodology (MLE, least squares).
• Flag survival analysis without right-censoring handling.

REMAINING USEFUL LIFE (RUL):

• Check for RUL prediction implementation.
• Verify confidence intervals on RUL estimates.
• Check for RUL prediction updates as new data arrives.
• Verify RUL is presented with uncertainty bounds, not point estimates.
• Flag RUL predictions without calibration or validation against historical failures.

HEALTH INDEX:

• Check for composite health index calculations (0-100 scale or similar).
• Verify the health index combines multiple indicators appropriately.
• Check for trending and rate-of-change analysis on health indices.
• Verify health index thresholds are calibrated against historical outcomes.

============================================================ PHASE 5: ALERT THRESHOLD ANALYSIS

THRESHOLD CONFIGURATION:

• Identify all alert thresholds in the system.
• For each threshold, determine:
  • How it was set (hardcoded, configurable, data-driven, domain expert).
  • Whether it is static or adaptive (adjusts based on operating conditions).
  • Whether it accounts for operating mode (startup, steady-state, shutdown).
  • Whether multiple severity levels exist (warning, critical, emergency).

ALERT LOGIC:

• Check for hysteresis / deadband on alerts (prevent alert flapping).
• Verify alert suppression during known conditions (maintenance mode, startup).
• Check for alert correlation (related alerts grouped, not individual floods).
• Verify alert priority and escalation logic.
• Check for alert fatigue mitigation (rate limiting, consolidation).
• Flag alerts that trigger on single data points without sustained condition checks.

ALERT ROUTING:

• Verify alerts route to appropriate recipients (operator, maintenance, management).
• Check for multi-channel notification (email, SMS, push, SCADA HMI, pager).
• Verify acknowledgment and close-out workflow exists.
• Check for alert history and audit trail.
• Flag critical alerts without escalation path if unacknowledged.

FALSE POSITIVE MANAGEMENT:

• Check for threshold tuning feedback loop (track false positive rate).
• Verify mechanism to adjust thresholds based on operational feedback.
• Check for alert analytics (frequency, false positive rate, response time).
• Flag systems with no false positive tracking.

============================================================ PHASE 6: MAINTENANCE SCHEDULING ANALYSIS

WORK ORDER GENERATION:

• Check for automatic work order creation from predictions and alerts.
• Verify work orders include: asset ID, predicted failure mode, urgency, required skills, estimated duration, required parts.
• Check for work order prioritization logic (criticality, production impact, safety).
• Flag maintenance triggers that require manual interpretation of model output.

SCHEDULING OPTIMIZATION:

• Check for maintenance window optimization (minimize production impact).
• Verify scheduling considers: production schedule, resource availability, part availability, regulatory requirements.
• Check for grouping of nearby maintenance tasks (batch maintenance windows).
• Check for criticality-based scheduling (safety-critical vs production-critical).
• Flag scheduling that does not consider production constraints.

FEEDBACK LOOP:

• Verify maintenance outcomes are recorded (was prediction correct? what was found?).
• Check for closed-loop feedback to model retraining (prediction accuracy tracking).
• Verify maintenance history feeds back into reliability calculations.
• Flag systems where maintenance outcomes are not captured for model improvement.

============================================================ PHASE 7: SPARE PARTS INVENTORY INTEGRATION

PARTS PREDICTION:

• Check for spare parts demand forecasting tied to failure predictions.
• Verify bill of materials (BOM) is linked to failure modes.
• Check for parts lead time consideration in scheduling.
• Flag maintenance scheduling without parts availability validation.

INVENTORY INTEGRATION:

• Check for integration with inventory management (ERP, CMMS, standalone).
• Verify real-time stock level checks before work order creation.
• Check for automatic reorder point triggers based on predicted demand.
• Verify parts reservation for scheduled maintenance.

CMMS/ERP INTEGRATION:

• Identify integration points with CMMS (SAP PM, Maximo, Fiix, UpKeep) or ERP.
• Check for bidirectional data flow (predictions -> CMMS, outcomes -> PdM system).
• Verify API error handling and retry logic for integrations.
• Check for data synchronization and conflict resolution.
• Flag one-way integrations that prevent closed-loop feedback.

============================================================ PHASE 8: SECURITY & OPERATIONAL SAFETY

OT/IT SECURITY:

• Check for network segmentation between OT and IT systems.
• Verify authentication on all data ingestion endpoints.
• Check for encrypted communication for sensor data in transit.
• Verify access control on model management and threshold configuration.
• Flag sensor data endpoints accessible without authentication.

SAFETY CONSIDERATIONS:

• Verify the system cannot suppress safety-critical alerts.
• Check for manual override capability on all automated actions.
• Verify fail-safe behavior (what happens when the PdM system goes down?).
• Check for human-in-the-loop for critical maintenance decisions.
• Flag any automated actions that bypass safety interlocks.

============================================================ SELF-HEALING VALIDATION (max 2 iterations)

After producing output, validate data quality and completeness:

1. Verify all output sections have substantive content (not just headers).
2. Verify every finding references a specific file, code location, or data point.
3. Verify recommendations are actionable and evidence-based.
4. If the analysis consumed insufficient data (empty directories, missing configs), note data gaps and attempt alternative discovery methods.

IF VALIDATION FAILS:

• Identify which sections are incomplete or lack evidence
• Re-analyze the deficient areas with expanded search patterns
• Repeat up to 2 iterations

IF STILL INCOMPLETE after 2 iterations:

• Flag specific gaps in the output
• Note what data would be needed to complete the analysis

============================================================ OUTPUT

Predictive Maintenance Analysis Report

Stack: {detected stack}

Architecture: {edge/cloud/hybrid}

Assets Monitored: {count} types, {count} sensor signals

Overall PdM Maturity Score: {score}/100

Maturity Level: {Level 1-5}

• Level 1 (0-20): Reactive -- no predictive capability, run-to-failure.
• Level 2 (21-40): Basic -- time-based preventive maintenance with some monitoring.
• Level 3 (41-60): Developing -- condition monitoring with basic analytics.
• Level 4 (61-80): Advanced -- ML-based prediction with integrated scheduling.
• Level 5 (81-100): Optimized -- closed-loop, adaptive, fully integrated PdM.

Subsystem Scores

Critical Findings

1. {PDM-001}: {title} -- Severity: {Critical/High/Medium/Low}
   • Subsystem: {subsystem}
   • Location: {file:line}
   • Issue: {description}
   • Impact: {unplanned downtime, safety risk, data loss, model degradation}
   • Fix: {specific recommendation}

ML Model Inventory

Alert Configuration Summary

Recommendations (ranked by impact on uptime)

1. {recommendation} -- impact: {description}, effort: {S/M/L}
2. ...
3. ...

DO NOT:

• Assume sensor data formats without reading the actual ingestion code.
• Flag time-based maintenance as wrong -- it is valid for some failure modes.
• Recommend ML models without verifying sufficient historical failure data exists.
• Ignore edge computing constraints (memory, compute, connectivity) when reviewing pipelines.
• Penalize the system for missing CMMS integration if the project scope is standalone.
• Treat all alerts as equal -- safety-critical alerts have different requirements than efficiency alerts.
• Recommend removing manual overrides on safety-critical systems.

NEXT STEPS:

• "Run /production-optimizer to analyze production scheduling alongside maintenance windows."
• "Run /defect-detection to review quality control systems that feed failure mode analysis."
• "Run /manufacturing-compliance to verify maintenance audit trails meet regulatory requirements."
• "Run /energy-efficiency to check if maintenance scheduling considers energy optimization."
• "Run /iterate to implement the critical findings."

============================================================ SELF-EVOLUTION TELEMETRY

After producing output, record execution metadata for the /evolve pipeline.

Check if a project memory directory exists:

• Look for the project path in ~/.claude/projects/
• If found, append to skill-telemetry.md in that memory directory

Entry format:

### /predictive-maintenance — {{YYYY-MM-DD}}
- Outcome: {{SUCCESS | PARTIAL | FAILED}}
- Self-healed: {{yes — what was healed | no}}
- Iterations used: {{N}} / {{N max}}
- Bottleneck: {{phase that struggled or "none"}}
- Suggestion: {{one-line improvement idea for /evolve, or "none"}}

Only log if the memory directory exists. Skip silently if not found. Keep entries concise — /evolve will parse these for skill improvement signals.