MSME Idea Hackathon 6.0 · Ref. 26INC06MH043254 · Rupesh Bharambe
I tested your local setup end-to-end. Everything below is verified against what actually renders on your machine — including three screens you should not open. Read §A and §D before anything else.
Two terminals, in E:\Projects\Gridalytics.
Terminal 1 — backend:
python -m uvicorn src.api.main:app --port 8000Terminal 2 — frontend:
cd frontend && npm run devThen open http://localhost:3000. No internet needed — I switched you to the local SQLite database.
| File | Change | Revert |
|---|---|---|
.env |
DATABASE_URL → sqlite:///./data/edfs.db |
Backup saved at .env.backup.presentation |
frontend/src/app/(dashboard)/accuracy/page.tsx |
Lookback 60 → 200 days; log heading reworded | git diff to see, git checkout to undo |
Why the .env change: your data/edfs.db holds the full dataset — 202,231 demand rows, 46,062 weather rows, and the 30-row prediction log behind your 0.97% figure. It runs with zero network dependency, which is exactly what you want on stage.
| ✅ | Task |
|---|---|
| ☐ | Both servers started, http://localhost:3000 loads |
| ☐ | Open 3 tabs: /accuracy, /forecast, /models |
| ☐ | On /forecast: set date 2026-03-25, resolution Hourly, click Predict — leave it on screen |
| ☐ | Screenshot those 3 pages as backup |
| ☐ | PPT open in Presenter View (notes are on every slide) |
| ☐ | Do not open /what-if or the Dashboard heatmap — see §D |
Your local database ends 2026-03-29. Today is 2026-08-18 — about 4.5 months later.
Nothing is broken; it's a snapshot. But it means anything that asks "what happened today?" comes back empty, while anything that looks at the historical record works perfectly.
This is why the demo below uses 2026-03-25 as its date. If asked, the honest answer is:
"This is running on a local snapshot of the database rather than the live feed — my free hosting tier ran out, so the automated 6-hourly ingestion is paused. The historical record and all the tracked accuracy is intact, which is what I'm showing you."
That's a hosting-budget fact, not a system flaw. Say it once, calmly, and move on.
Timings: ~5 min slides + ~2.5 min demo. Speaker notes are also inside the PPT.
"Good morning. I'm Rupesh Bharambe, and I built Gridalytics — a real-time AI platform that forecasts electricity demand to make the power grid measurably more energy-efficient.
This is under the Energy Efficiency theme. The one thing I'd ask you to hold onto: this is a working system, not a concept. I'll show it running at the end."
"India's peak electricity demand crossed roughly 250 gigawatts in 2024, and it keeps climbing — AI data centres, EVs, industrial growth.
Here's the part that isn't obvious. Operators do forecast demand. But most forecast only coarse daily load — one number for the day. And electricity isn't wasted at the daily level. It's wasted in the intraday ramps — the overnight dip, the morning climb, the evening peak. If your forecast can't see those, you're planning blind.
So operators pad with a safety margin. They over-generate and burn fuel nobody uses. They hold expensive spinning reserves, fire up polluting peaker plants at short notice, and pay drawal penalties. And renewables — inherently variable — get harder to absorb.
As demand gets more volatile, this stops being optional."
Land this line: "Energy is wasted in the ramps, not in the daily average."
"Gridalytics removes the guesswork. Four steps.
We ingest live SCADA demand from the Delhi grid, plus weather, air quality, and India's holiday and festival calendar. We engineer 93 features. A model ensemble forecasts at three resolutions. And we serve it through an API and dashboard.
The goal isn't a better research model. It's letting a load-despatch centre schedule generation precisely instead of padding it."
"What's actually running.
Data — Delhi SLDC publishes SCADA demand every five minutes. We pull that, plus weather and air quality from Open-Meteo, plus Indian holidays and festivals — Diwali, Holi, even IPL match days, because they visibly move load.
Ingestion — GitHub Actions runs every six hours, automatically. We're holding over 200,000 demand readings spanning 2021 to 2026.
Features — 93 of them. Lags at 1 hour, 24 hours, 168 hours. Rolling statistics. Fourier terms for daily and weekly seasonality. Cooling and heating degree days.
Models — seven trained and evaluated: LightGBM, XGBoost, a PyTorch BiLSTM, SARIMAX, NeuralProphet. Tuned with Optuna, validated with walk-forward cross-validation.
Serving — FastAPI with 27 endpoints behind a 10-page dashboard.
Automated retraining and drift detection included — this is a pipeline, not a notebook."
"Four differentiators.
Multi-resolution — 5-minute, hourly and daily from one system, out to 90 days. That's what resolves the ramps.
Honest validation — walk-forward cross-validation, zero data leakage. That matters because it's easy, and common, to let a model peek at future data and report a number that collapses in production. I validated the hard way. My previous version had exactly that leakage problem, and fixing it is most of why this one is trustworthy.
Sub-regional and scenario intelligence — each Delhi DISCOM forecast separately, because a city-level number doesn't help a distribution company.
Production MLOps — ingests every six hours, retrains weekly, detects its own drift. Most forecasting work stops at the paper. I deployed it and watched it."
"Measured numbers, not projections.
0.18% MAPE at 5-minute resolution. 0.52% hourly with XGBoost.
But the number I care about is the third. In live production — predicting forward, then comparing against what actually happened — 0.97% average error across 29 consecutive tracked days. Not a backtest. The system being right, day after day, on data it had never seen.
Against the baseline I started from: 137 times more accurate, models 49 times smaller.
And I'll show you that tracking log in a moment — every prediction, every actual, every error."
"Next.js dashboard, FastAPI backend, 27 endpoints, JWT auth. LightGBM, XGBoost, PyTorch, SARIMAX, NeuralProphet. Supabase Postgres. Optuna, walk-forward validation, drift detection.
Deployed across Vercel, Render, Supabase and GitHub Actions — and I built the whole thing to run at zero infrastructure cost. That constraint is why scaling to another state is mostly just compute I already know how to size."
"The primary customer is the State Load Despatch Centre — day-ahead and intraday scheduling — and DISCOMs, for procurement and avoiding drawal penalties.
The same forecast serves power exchanges for bidding, gencos for ramp planning, and increasingly EV charging networks and smart-city energy management. Same engine, different subscriber."
"Efficiency — less over-generation, less fuel burned for nothing. Reliability — lower reserves, better peak-shaving. Cost — fewer penalties and losses. Sustainability — smoother renewable integration, because you can match variable supply to an accurate demand curve.
And the business case in one sentence: even a one percent improvement in forecast accuracy saves a grid crores. I improved on my baseline by far more than one percent."
"Countable market. 36 State Load Despatch Centres, one per state and UT. Over 70 DISCOMs. Five regional centres and one national. Every one has this exact problem.
Globally, AI-in-energy analytics is a multi-billion-dollar market growing double-digit. This is B2B SaaS — recurring revenue, high margin, near-zero cost to serve."
"Delhi is the proof of concept. Next is state by state — and critically, it's the same engine, retrained on local data. No re-architecture. Then a national multi-DISCOM platform, then demand response and EV load."
Order matters. Lead with Accuracy. It's your strongest artefact and it renders perfectly.
Go to the /accuracy tab.
"This is the page I'd point a sceptical engineer at first.
Every prediction the system made got logged, and then compared against what actually happened. Average error: 0.97 percent. Mean absolute error: 8.4 megawatts. Twenty-nine days tracked. Best day, 0.37 percent. Drift status: stable.
And here's the full log — every date, predicted peak against actual peak, and the error."
Scroll the table slowly.
"Look at the consistency — almost every day under one percent, worst case just under two. And these notes are automatic: it flags holidays, and it flags when the actual peak hour shifted away from the predicted one. That's the system being honest about its own misses.
This is real production performance, not a backtest."
Verified showing: AVG MAPE 0.97% · MAE 8.4 MW · 29 days · best 0.37% · drift stable · 29-row log
Switch to the /forecast tab (already run). If not: date 2026-03-25, resolution Hourly, Predict.
"Now the forecast itself. I've asked it for the 25th of March — a past date, so you can see prediction and reality on the same axes.
Peak 4,047 megawatts at 11am. Minimum 2,647 overnight. Total energy 83.9 million units.
Now look at the curve shape — that's the whole argument. The overnight trough, the morning ramp, the peak, the evening decline. A daily-average forecast would be a flat line through the middle of this, and every gap between that flat line and this curve is either wasted generation or a shortfall."
Point at the actual-demand series and the confidence band.
"The second series is what actually happened — they track almost on top of each other. And the shaded band is the confidence interval, because an operator needs to know how much to trust the number, not just the number.
And it exports to CSV or PDF, because despatch engineers work in spreadsheets."
Verified showing: Peak 4047 MW @ 11:00 · Min 2647 · Avg 3497 · 83.9 MU · model xgboost · actual overlay · confidence band · CSV/PDF
Switch to /models.
"And this is every model, with its real validated metrics side by side. LightGBM at 5-minute — 0.18% error, R-squared 0.9997. XGBoost hourly at 0.52%. Down through SARIMAX, the BiLSTM, NeuralProphet.
Seven models trained and evaluated; five loaded in production. I keep the weaker ones as benchmarks — that's how I know the champion is actually the champion.
And this bottom table is the comparison against my previous system, which had the data-leakage problem I mentioned."
If asked about "5 trained models" in the header vs 7 cards:
"Five have deployed model artefacts loaded in memory; seven were trained and evaluated. The header is counting what's loaded."
| Screen | What a judge would see | If you're asked to show it |
|---|---|---|
| /what-if | I tested a 45°C heatwave on it: it reports 0.0% impact, 0 MW. The override isn't reaching the features on in-range dates. Contradicts your own slide. | "The scenario engine's re-forecast path needs the live weather feed, which is paused on this local snapshot — I'd rather show you the tracked accuracy than a half-working screen." |
| Dashboard heatmap | Renders "Infinity MW / -Infinity MW" — no data in the recent window. | Just don't scroll there. |
| Forecast for any date after 2026-03-29 | Curve collapses to a near-flat line (~120 MW swing vs the real ~1,400 MW). Recursive forecasting past the data end. | "Beyond the snapshot's end date it has no lag features to stand on — that's what the live 6-hourly ingestion provides." |
Dashboard (/) — partial. Current Demand (3,789 MW), Temperature, and the DISCOM Breakdown all work. But Today's Peak, Model Accuracy, This/Last Week Avg all show ---, and it prints "Data: 3397h ago" at the top. If you open it, stay on the DISCOM breakdown and don't linger. Safer: skip the Dashboard entirely — Accuracy, Forecast and Models are strictly stronger.
Open http://localhost:8000/docs
"And all of it is a documented API — 27 endpoints. This isn't a dashboard with a model bolted on; the forecast is a service any despatch system can call."
Back to the PPT.
"To close with one number. Every one percent of forecast accuracy is crores saved in fuel, penalties and reserves — for a single grid.
Gridalytics exists to make India's electricity system measurably more efficient, more reliable, and ready for the demand growth coming from AI, EVs and industry. I built it end to end, and it works.
Thank you. I'd be glad to take questions."
"0.5% error on a 90-day forecast is not believable."
They'd be right to push. Answer precisely — it earns credibility:
"Let me be exact, because those are two different numbers. The 0.52% is one-step-ahead accuracy — forecasting the next interval with actual weather known. That's the number that governs intraday scheduling, which is the primary use case.
Multi-day recursive forecasting is a harder problem and the error is genuinely higher — low single digits — because the model feeds its own predictions back as inputs, so errors compound, and because you're relying on a weather forecast rather than actual weather. I measure them separately and I don't conflate them. The 0.97% on the slide is live tracked day-ahead performance, which is the most honest number I have."
Never claim 0.5% for long-horizon forecasting. You have a genuine known limitation here — recursive collapse past the data horizon — and volunteering the distinction is what separates you from someone who doesn't understand their own model.
"I built all of it — data pipeline, feature engineering, all seven models, the API, the dashboard, and the deployment. That's precisely why I know every failure mode in it, including the ones I just described to you. For scaling to multiple states I'd need help on integration and support, and that's exactly what I'd use this programme's backing for. What I've proven is that the hard technical core is done and working."
Don't apologise for being solo. A working production system built by one person is a stronger signal than a team with a slide deck.
"Delhi SLDC publishes it publicly every five minutes — that's what I scrape. For a commercial deployment we'd integrate directly with the utility's SCADA, which is cleaner and lower-latency. The public feed let me prove the concept without needing anyone's permission first."
"It's the dominant error source in multi-day forecasting and I'm explicit about it. I use 16-day Open-Meteo forecast data. The confidence bands widen accordingly, and the scenario engine is designed so an operator plans against a range rather than betting on one outcome."
"Different models win at different resolutions — LightGBM dominates at 5-minute and hourly, classical SARIMAX is competitive at daily where there's less data. Keeping the others gives a production fallback and an honest benchmark."
"Subscription per grid entity — SLDC, DISCOM or trader. The ROI argument is simple: if one percent of accuracy saves crores in fuel and penalties, a subscription in lakhs is easy. My infrastructure cost is near zero, so margin is high."
"Some will. But the hard part isn't the model — it's five years of cleaned historical data, 93 engineered features, validation methodology that doesn't lie to you, and the MLOps to stay accurate in production. That's built and deployable in weeks, not years."
"Free hosting tier ran out — that's a budget line, not an engineering problem. It ran live for a month with the accuracy tracking you just saw. Restoring it is a hosting cost, and it's the first thing funding would cover."
- Lead the demo with /accuracy. It's your best evidence and it works flawlessly.
- Land "0.97% across 29 live days." It's the most persuasive sentence you have.
- Say "I built this end to end" once, plainly. Solo delivery of a working system is a credential.
- If a screen misbehaves, name the reason in one sentence and move on. Judges forgive infrastructure; they remember panic.
- Slow down on slides 4 and 6. Everything else can move.
- Don't read the slides — the slides are for their eyes, your voice adds the argument.
- Finish crisply. Ending on time reads as competence.
One-line fallback for anything unexpected:
"That's the local snapshot rather than the live feed — let me show you the tracked accuracy instead, which is the real proof."