Machine Learning · Energy
GridCast AI
A full-stack machine learning platform for forecasting short-term electricity demand across Great Britain — combining a production-style ML pipeline, explainable AI, and an interactive analytics dashboard.
Overview dashboard — system status, live demand metrics, and 48-hour forecast at a glance.
Overview
GridCast AI takes historical half-hourly electricity demand data from the National Energy System Operator, processes it through an engineered feature pipeline, trains forecasting models, and serves predictions through a FastAPI backend. A Next.js dashboard consumes the API to visualise forecasts, regional demand, model performance, and prediction explanations.
The goal was to treat the forecasting model as one component within a complete software product — demonstrating the full lifecycle from data ingestion to a usable interface, rather than stopping at a notebook.
- —48-hour electricity demand forecasting with confidence intervals.
- —FastAPI backend serving forecasts, SHAP explanations, and simulation endpoints.
- —Interactive Next.js dashboard with regional demand mapping and scenario simulation.
- —Explainable AI — feature importance and local prediction reasoning built into the UI.
The Problem
Most machine learning portfolio projects end at a Jupyter notebook. They demonstrate modelling techniques but rarely show how predictions are served, monitored, explained, or presented to users.
GridCast AI was built to bridge that gap — treating the model as one component within a production-style system, with clear API boundaries, explainability, and an interface that makes model outputs understandable rather than simply displaying raw numbers.
Forecast analytics — 48-hour demand forecast, confidence intervals, and statistical decomposition.
Design Decisions
The dashboard is split into distinct analytical views rather than presenting everything on a single screen. Operational monitoring, forecast analysis, regional demand, scenario simulation, and explainability each have dedicated interfaces — allowing users to move from high-level metrics to individual prediction reasoning without the interface becoming overwhelming.
Every forecast is accompanied by confidence intervals, feature importance, and SHAP explanations. Raw model outputs are rarely sufficient — the interpretability layer is what makes the system genuinely useful rather than opaque.
Implementation
The backend follows a modular ML architecture with independent ingestion, preprocessing, feature engineering, training, inference, evaluation, and explainability modules. Historical NESO demand data is validated and transformed into model-ready features before baseline models are compared and the selected model is persisted as an artifact.
FastAPI serves forecasts, historical demand, SHAP explanations, and scenario simulations through typed REST endpoints. The Next.js frontend communicates exclusively through this API layer, keeping the dashboard completely decoupled from the underlying model implementation.
Frontend
Next.js · TypeScript
Interactive dashboard with forecast analytics, regional demand mapping, scenario simulation, and explainable AI visualisations.
Backend
FastAPI · Python
REST API serving forecasts, model metadata, SHAP explanations, historical demand, and simulation endpoints.
Machine Learning
XGBoost · scikit-learn · SHAP
Feature engineering, model comparison, recursive 48-hour forecasting, evaluation metrics, and explainable predictions.
Data Pipeline
NESO Historic Demand Data
Validation, preprocessing, lag feature generation, rolling statistics, training dataset creation, and model artifact generation.
Regional grid map — demand visualised across GB with switchable layers.
Scenario simulation — what-if forecasting with adjustable operational variables.
Model insights — global feature importance across all forecast points.
Local explanations — SHAP waterfall chart for individual forecast reasoning.
What I Learned
- —Feature engineering matters more than model selection. The quality of lag features, rolling statistics, and temporal encodings had a larger impact on forecast accuracy than switching between model architectures.
- —Production-style ML requires careful separation of concerns. Treating ingestion, training, inference, and explainability as independent modules made the system far easier to reason about and extend.
- —Explainability is most valuable when it's built into the interface from the start — not added as an afterthought. Users interacting with SHAP charts develop real intuition about model behaviour rather than simply trusting outputs.