Skip to content
← Back to work
Case Study / GridPulse

GridPulse

I led product direction and delivery for GridPulse, a live tool for reviewing electricity demand forecasts, observed error, and data quality across 51 US balancing authorities.

51 balancing authoritiesPublished forecast + observed errorSeparate training evaluationsLive dashboard + read-only API

Overview

GridPulse is intended for analysts examining regional electricity demand and forecast performance using public data. The live dashboard brings forecast sources, observed error, demand, weather, and data-quality warnings into one review workflow across 51 US balancing authorities.

A forecast curve alone does not explain whether it needs attention. GridPulse puts the evidence behind that review alongside the forecast.

RoleProduct direction and delivery
Year2024
IndustryEnergy / Power markets
StackDash · Cloud Run + Memorystore Redis + GCS · XGBoost · Prophet · SARIMAX
StatusLive application

My role

I took GridPulse from product scope to a deployed dashboard and read-only API. I set the priorities, defined the review workflow, and directed how forecast sources, accuracy evidence, and data quality are presented.

The delivery includes scheduled forecast updates, model evaluation, and data-quality disclosures. An evidence audit shaped the current source labels, clock definitions, and scoring-coverage display, including keeping model comparisons separate from the published forecast.

The review decision

The primary question is: Does this demand forecast need closer review?

  1. Identify the forecast shown and whether it is the GridPulse published forecast or a selected model comparison.
  2. Check its generation time, target window, matching error evidence, scoring coverage, and data warnings.
  3. Review the next demand peak, forecast curve, demand history, and weather to decide what to investigate.

Demand and forecasts

Overview starts with the next 24 hours of the GridPulse published forecast, its next peak and time, and the latest reported demand. This is a rolling target window. The published forecast can be a trained model or a seasonal baseline; its source and recorded selection reason are disclosed. Historical demand observations are available in an expandable section.

The error panel identifies the series, scoring window, sample count, and available target-hour coverage. Its horizon offsets are measured from the first forecast target, rather than an exact lead from the publication clock. Training holdouts remain separate. Missing counts or timing evidence stay explicitly unknown.

GridPulse Overview for Florida (FPL), showing the published baseline, target window, generation time, and observed error with scoring coverage.

GridPulse Overview for Florida (FPL), with the published baseline, target window, generation time, and observed error with scoring coverage. Captured October 25, 2026.

View full-size screenshot ↗

Four review contexts offer different starting views and historical summaries. They share the same demand data, KPIs, and forecasts.

The US Grid view compares balancing authorities using reported demand, interchange, and capacity context. The demand-to-nameplate-capacity ratio is a comparison metric. Available reserves and shortage risk need separate assessment.

Model evaluation

The Models view compares XGBoost, Prophet, SARIMAX, and a weighted ensemble using their last completed 168-hour recursive training holdouts. MAPE is mean absolute percentage error; lower is better. MAE and RMSE measure error in megawatts.

Observed error on past forecasts and training holdout error answer different questions. Neither is presented as the expected accuracy of the next forecast. Published results include balancing authorities where a single model outperforms the ensemble.

A separate benchmark compares named model series with operator day-ahead forecasts on matched observations. Its scored series can differ from the published default; the benchmark identifies the model and evaluation window rather than assigning its score to every forecast in the dashboard.

Where model forecast bands are available, the chart identifies whether they use backtest error ranges or an indicative envelope. The seasonal baseline does not borrow a trained model's score or forecast band.

Weather scenarios

The Forecast view lets users adjust temperature, wind, and solar assumptions or choose a preset. Results compare demand estimates with a named reference forecast and identify the calculation method used.

Delivery and reliability

Scheduled jobs fetch data, score forecasts, and retrain models. The Dash web service reads cached results from Redis, while model artifacts are stored in Google Cloud Storage. A read-only API exposes the same cached data for use outside the dashboard.

The interface discloses stale forecasts, provisional EIA readings, and excluded reporting artifacts. A recent timestamp can still accompany incomplete or provisional inputs.

A three-region pilot captures published-forecast evidence after successful persistence, preserving the series, generation time, target values, and recorded selection context. This prospective record is separate from legacy chart replay. A historical operating-day review remains planned while verified publication history accumulates.

Project notes

GridPulse is an independent project using public data. Published industry procedures informed the proposed analyst workflow.

Developed with AI assistance.

Practitioner validation of the review workflow and its operational value is the next step. Analyst adoption and business impact have not been validated.