Skip to content

Saurabh Sagar ShindeCS undergraduate · K. K. Wagh Institute, Nashik · ML and intelligent systems

Open to research collaboration · About me

A prediction of remaining life is only as good as the decision it supports.

Models that forecast when a machine will fail are usually judged on accuracy. I study what a maintenance decision actually needs from them: calibrated uncertainty, and an explicit account of what it costs to act too early or too late.

Predictive maintenance: from sensor history to a maintenance decisionIllustrative schematic, not actual model output. Observed health declines over operating cycles. The median forecast and uncertainty band extend from the present. The plausible failure window runs from cycle 93 to cycle 109, with median failure near cycle 100. A maintenance decision is scheduled at cycle 89, before the earliest plausible failure.0.00.51.0032.56597.5130Operating cyclesHealth indicatorFailure thresholdNowPlausible failure windowMaintain

Each button highlights one part of the figure and explains it below.

Select a part of the figure to see what it represents.

Illustrative · synthetic valuesFig. 0 — A conceptual instrument: an abstract machine, its observed health, a forecast with its uncertainty envelope, the window where failure becomes plausible, and a maintenance decision placed before it.

Current researchIn progress

Decision-theoretic predictive maintenance with calibrated uncertainty — manuscript in preparation, on NASA C-MAPSS.

Graduating July 2027 (expected) · open to research collaboration: saurabhsshinde16@gmail.com

The research question

When a model predicts how long a machine will keep working, how much should a maintenance decision trust that prediction — and what should it do with the uncertainty?

My research direction is uncertainty-aware decision intelligence for operational systems: treating prediction, uncertainty and the decision as one system, and judging it by what the decision costs.

  1. Step 1

    A prediction

    A single remaining-life estimate says when failure is most likely — not how wrong it might be.

  2. Step 2

    Its uncertainty

    A calibrated interval states how wrong it might be, at a rate you can check on held-out data.

  3. Step 3

    A decision

    With the costs of acting early and failing late made explicit, the interval determines when to act.

Current project · independent research · 2026 – present

Decision-Theoretic Predictive Maintenance with Calibrated Predictive Uncertainty for Remaining Useful Life Prediction

A remaining-useful-life (RUL) model that is accurate on average can still be wrong in exactly the cases that matter: an engine that fails sooner than predicted. Maintenance decisions are asymmetric — servicing too early wastes useful life, servicing too late risks failure — so a single predicted number is not enough to decide well.

Status
Manuscript in preparation
Data
NASA C-MAPSS turbofan engine degradation simulation
Results
None reported yet
Read the full research overview

The pipeline, stage by stage

Six stages carry a sensor history to a maintenance decision and its evaluation. Each stage’s output is the next stage’s input; the decision consumes the whole calibrated distribution, not only its centre.

Being implementedPlanned

Sensor and time-series inputs

In progress

Run-to-failure sensor trajectories from NASA C-MAPSS, cut into multivariate time windows.

  • Each training example is a window of recent sensor readings from one engine.
  • The target is that engine’s remaining useful life at the end of the window.
In
Simulated turbofan sensor histories
Out
Multivariate sensor windows
Fig. 1 — The research pipeline, from sensor data to a maintenance decision and its evaluation. Select a stage to read what it does. Stage status follows the CV; nothing here reports a result.

Uncertainty and decisions, demonstrated

Two interactive demonstrations built from documented formulas and labelled Illustrative. They show what the method is for. Empirical figures — coverage, interval width and decision loss on held-out C-MAPSS engines — will appear only when the experiments that produce them are complete.

Predicted remaining useful life with a prediction interval

Illustrative · synthetic values
  • True RUL
  • Predicted RUL
  • Prediction interval
  • Safety margin (20 cycles)
Illustrative predicted remaining useful life with a prediction intervalSynthetic data. True remaining useful life is capped at 125 cycles, then falls to zero at cycle 200. The prediction interval narrows as failure approaches, from about 36 cycles wide at cycle 30 to about 8 cycles wide at cycle 190. At the selected cycle 110, the predicted RUL is 99 with interval 86 to 113; the true RUL is 90, which is inside the interval. A simple rule raises a maintenance alert when the interval’s lower bound first reaches the 20-cycle safety margin, at cycle 175; at the selected cycle it has not yet been raised.050100150050100150200Operating cycleRUL (cycles)Safety marginFailure (RUL = 0)
Predicted RUL
99
Interval
[86, 113]
Width
28
True RUL inside?
Yes (90)
Alert raised?
Not yet

Fig. 2 — What a calibrated interval is meant to do: contain the true remaining life at a stated rate, and tighten as evidence of degradation accumulates. Drag the cycle to see where this synthetic interval does and does not contain the truth, and when a simple interval-based rule would call for maintenance.

How it was generated: true RUL = min(125, 200 − cycle); predicted = true RUL plus a smooth deterministic error; interval half-width = 3 + 0.12 × true RUL. No model was trained. Real coverage is measured across many held-out engines, not along one trajectory. The alert rule (lower bound ≤ 20 cycles) is a teaching device, not the expected-loss policy studied in the research.

Expected maintenance loss by maintenance timing

Illustrative · synthetic values
  • Expected loss
  • Failure-risk term
  • Wasted-life term
Illustrative expected maintenance loss as a function of maintenance timingToy model with predicted RUL 60 cycles and predictive standard deviation 12 cycles, failure cost 20, and 0.25 per cycle of unused life. Expected loss is lowest when maintaining 42.5 cycles from now, with expected loss 5.9 and a 7.2 percent chance of failing first. Maintaining at the point prediction, cycle 60, has expected loss 11.2.010.821.60306090120Maintain in m cyclesExpected loss (cost units)Point predictionPast m*: waiting adds more risk than it savesMinimum at m = 42.5
Best timing m*
42.5
P(fail before m*)
7.2%
E[loss] at m*
5.9
Trigger level cE/cF
0.0125
E[loss] at point prediction
11.289% higher than at m*

Change a cost or the uncertainty to see why the best time moves.

Fig. 3 — Why the decision needs the whole distribution. With remaining life R ~ Normal(60, σ) and maintenance scheduled m cycles from now, the expected loss is

E[L(m)] = cF·P(R ≤ m) + cE·E[(R − m)+]

The first term is the chance of failing before maintenance times the failure cost; the second is the useful life thrown away by maintaining early. The minimum satisfies h(m*) = cE/cF, where h is the hazard rate of the predictive distribution. Expensive failures pull m* earlier; when failure is cheap relative to wasted life, more uncertainty can push it later.

Toy model for explanation only: Normal predictive distribution (negative-RUL mass not truncated), static linear costs, one unit, no scheduling constraints, and cost units with no real-world calibration. It is not an evaluated maintenance policy and the numbers are not results.

Where the work stands

  • Hybrid temporal backboneIn progress
  • Conformalized quantile regressionIn progress
  • Risk-aware decision layerIn progress
  • Uncertainty-method comparisonIn progress
  • Predictive baselinesIn progress
  • Ablation studiesPlanned
  • Sensitivity analysisPlanned
  • Statistical significance testingPlanned
  • Decision and economic evaluationPlanned
  • Research code verification (448 tests passed, 0 failed, 32 skipped)Completed

Status follows the CV. Test counts verify the software, not the method’s performance.

Systems that reach people

Civic AI, legal access and full-stack products, built in teams and deployed to real users. Each case study separates my own contribution from the team’s.

Civic AI and retrieval-augmented generation · 2025 – present

Rakshak AI

Citizens in rural Nashik need a simpler way to reach police services, file complaints and get legal guidance — in Marathi or English.

My role: Co-developer. Frontend and application development. Built by a multidisciplinary team responsible for AI, backend, data and system architecture, in collaboration with Nashik Rural Police.

Read the Rakshak AI case study
  1. Who

    • Citizen
  2. Channel

    • WhatsApp
    • Voice / IVR (evolving)
  3. Conversation

    • Frontend and application layer (my contribution)
    • Bilingual dialogue (Marathi, English)
  4. Knowledge

    • Retrieval over police procedures and legal information
  5. Services

    • Complaint guidance
    • Lost-item reporting
    • Legal guidance
    • Station discovery
    • Emergency assistance
My contributionConceptual diagram from the project description — not the deployed architecture.
users
5,000+
First year after the 1 Sep 2025 launch, as reported by the team in its one-year update (Sep 2026).
police-related citizen conversations
51,376
Same one-year window. Conversations, not unique users.
complaints and reports received, assessed and resolved
86
Same one-year window, as reported by the team.
    1. Who

      • Citizen
      • Advocate
    2. Client

      • React frontend (Vercel) (my contribution)
    3. API

      • Express API, JWT + role-based access (AWS EC2, PM2) (my contribution)
    4. Features

      • Legal explorer: BNS, BNSS, BSA (my contribution)
      • Advocate discovery (my contribution)
      • Client–lawyer communication (my contribution)
      • Role-specific dashboards (my contribution)
    5. Data

      • Python legal-update scraper (my contribution)
    My contributionConceptual diagram from the project description — not the deployed architecture.

    Legal technology · full-stack · 2026

    NyayMargadarshak

    Indian legal information and access to lawyers are hard for citizens to navigate.

    Role: Full-stack developer.

    Read the case study
    1. Who

      • Person seeking legal information
    2. Interface

      • Conversational frontend (my contribution)
    3. Team components

      • Backend
      • AI components
    My contributionConceptual diagram from the project description — not the deployed architecture.

    AI legal assistant · 2025

    NyayBot

    Indian legal information is difficult for non-specialists to find and understand.

    Role: Designed and developed the frontend.

    Read the case study
    1. Give

      • Donor
    2. Platform

      • Frontend and UI/UX (my contribution)
    3. Fulfil

      • Verified supplier (vendor selection)
    4. Receive

      • NGO / receiver
    5. Check

      • Feedback-based quality check
    My contributionConceptual diagram from the project description — not the deployed architecture.

    Hackathon · 48 hours · 2025

    Shakti Link

    Donations to NGOs need transparency: donors, receivers and suppliers should be able to see that help arrived as intended, without direct cash transactions.

    Role: Frontend and UI/UX.

    Read the case study
    1. Who

      • Patient
    2. Interface

      • Web frontend and workflows (my contribution)
    3. Features

      • Appointment booking
      • Medical-history access
    My contributionConceptual diagram from the project description — not the deployed architecture.

    Healthcare web platform · 2024

    Nirvan Care

    Patients need one place to book appointments and see their medical history.

    Role: Frontend development and workflow design, in a collaborative team.

    Read the case study

Publications and manuscripts

Listed with the status the evidence supports. Links appear only where a public version exists.

  1. 2026

    Decision-Theoretic Predictive Maintenance with Calibrated Predictive Uncertainty for Remaining Useful Life Prediction

    Shinde, S. S., et al. · Manuscript in preparation

    A framework that links remaining-useful-life prediction, conformal prediction intervals and an expected-loss maintenance decision layer, evaluated on the NASA C-MAPSS turbofan benchmark.

    Contribution: Lead researcher on the framework, implementation and experimental protocol.

    Manuscript in preparationDetailsResearch overview
  2. May 2026

    Enterprise AI Agent Ecosystems: Architecture, Economics, and the Composition Gap

    Shinde, A., Shinde, S. S., Bava, N., Deodhar, A., and Gupta, V. · SSRN

    Analyses enterprise AI agent ecosystems across architecture, protocols, economics and adoption, and the gap between available agent capabilities and measurable enterprise value.

    Contribution: Co-author. Contributed to the analysis of agent discovery, selection, trust, governance and economic constraints that supports a proposed Trust-Aware Ranking System (TARS) for context-aware agent selection.

    PreprintDetailsNo public link yet
  3. July 2025

    Justice-as-a-Protocol: Designing a Stateless, Scalable, and Self-Enforcing Online Dispute Resolution (ODR) System for 21st Century India

    Shinde, S. S., et al. · ResearchGate

    Proposes an AI-assisted online dispute resolution architecture for the Indian legal ecosystem, integrating legal rules, multilingual access, digital workflows and automated enforcement.

    Contribution: Co-author. Led the system logic and built the frontend for the framework, working on how the legal rules are encoded into the platform's workflow.

    PreprintDetailsNo public link yet
  4. 2025

    From Chariots to Cavalry: The Evolution of Indian Warfare and the Fall of the War Chariot

    Shinde, S. S., and A. D. Thorat · Published research article

    A historical research article on the changing role of the war chariot in Indian warfare.

    PublishedDetailsNo public link yet

Experience and education

  1. 2026 – presentResearch

    Independent researcher

    Decision-theoretic predictive maintenance with calibrated uncertainty

    • Manuscript in preparation.
  2. Sep 2025 – presentProject

    Co-developer, Rakshak AI

    In collaboration with Nashik Rural Police

    • Frontend and application development within a multidisciplinary team.
  3. Sep 2025 – Mar 2026Industry

    Full-Stack Developer Intern

    DreamCare Developers Pvt. Ltd.

    • Contributed to government-oriented web applications and citizen-facing digital systems.
    • Full-stack development, frontend implementation and web application workflows.
  4. 2025Industry

    Web Development Intern

    Cognifyz Technologies

    • Frontend implementation, application workflows and practical software development.
  5. Expected July 2027Education

    B.E., Computer Engineering

    K. K. Wagh Institute of Engineering Education & Research, Nashik

    • CGPA 8.0 / 10

Relevant coursework

Probability and Statistics, Engineering Mathematics, Statistical Methods, Data Structures and Algorithms, Database Management Systems, Machine Learning, Artificial Intelligence, Computer Networks, Operating Systems, Object-Oriented Programming, Software Engineering.

Recognition

  • Rakshak AI received institutional and public-sector recognition for its work with Nashik Rural Police, including presentation of the project to the Governor of Maharashtra on 2 January 2026.
  • UK Design Registration for “Communications Equipment for Public Safety” (Rakshak AI team), 2026.
  • Tech Horizon 2025 national-level hackathon — built Shakti Link under a 48-hour constraint.
  • Completed Econometrics: Methods and Applications (Erasmus University Rotterdam, via Coursera, June 2025) — regression, time-series and panel-data methods, causal inference, instrumental variables.
  • AWS Academy Graduate — Cloud Foundations (Amazon Web Services, March 2026).

Leadership and community

  • Co-founder and CEO, Neuronex Developers (since Sep 2025)
  • Secretary, Rotaract Club of Nashik Nine Hills (Rotary year 2026–27)
  • Member, Beyond the Horizon college magazine team (since Mar 2026)
  • Member, ISTE student chapter, KKWIEER (since 2023)

Methods and tools

Uncertainty and decision science
Conformal prediction, Conformalized quantile regression, Calibration, Prediction intervals, Deep ensembles, MC dropout, Expected-loss decisions, Sensitivity analysis, Statistical testing
Deep learning
PyTorch, TCN, Transformers, Attention, LSTM, GRU, CNN, Multi-quantile regression
Machine learning
scikit-learn, XGBoost, LightGBM, Ensemble learning, Regression, Classification
Data and statistics
Pandas, NumPy, SciPy, Time-series analysis, Hypothesis testing, Econometrics
AI and research practice
RAG, LLM applications, AI agents, Multi-agent systems, Experimental design, Ablation studies, Benchmarking
Web and systems
React, Node.js, Express, REST APIs, JWT, Tailwind CSS, SQLite, AWS EC2, Vercel, PM2, Git, Linux
Programming languages
Python, Java, C++, JavaScript

The person behind the research

Portrait of Saurabh Sagar Shinde in a navy suit and tie, arms folded, smiling slightly.

Saurabh Sagar Shinde · Nashik, Maharashtra, India

I study how machine-learning predictions should be trusted when real decisions depend on them.

I’m a computer engineering undergraduate at K. K. Wagh Institute of Engineering Education & Research in Nashik, working on uncertainty-aware decision intelligence: predicting how long a machine will keep working, attaching honest uncertainty to that prediction, and turning both into a maintenance decision.

Alongside research I build systems people use — most visibly Rakshak AI with Nashik Rural Police. Seeing how deployed systems are actually used, and where they fail, shapes which research questions I think are worth asking.

  • Predictive maintenance / prognostics and health management
  • Remaining useful life prediction
  • Uncertainty quantification
  • Conformal prediction
  • Decision-theoretic machine learning
Read the full profileResearch, story, roles and what collaborators say

Let’s talk research.

For research collaboration, supervision, or engineering conversations — email is the best way to reach me.