Enefit Prosumer Forecasting
An energy forecasting system with strict data contracts, separate consumption and production artifacts, baseline leaderboards, walk-forward backtests, serving paths, metrics, and demo evidence packs.
What it is
The product framing is forecast reliability for prosumer energy consumption and production.
The system is useful because the output can be served through an API or batch/CLI path while carrying metadata about the model, feature contract, and run artifacts.
The loop it has to make believable
- 01
Built separate consumption and production model artifacts rather than forcing one target shape.
- 02
Used strict feature contracts across training, API inference, and CLI inference.
How it’s built
The hard part is avoiding time leakage. Weather, prices, target history, rolling features, and splits all need explicit handling.
The repo also proves serving discipline: the same feature contract is used across training, API, and CLI inference.
Architecture
- Data path
- Raw Kaggle tables, schema validation, raw/staged/feature parquet layers, lineage reports, causal joins
- Model layer
- Separate consumption and production LightGBM artifacts, optional uncertainty path, and baseline leaderboards
- Evaluation
- Holdout metrics, per-target reports, walk-forward backtests, ablation matrix, robustness report
- Serving
- FastAPI and CLI inference reuse the same feature contract and saved production pointers
What has to hold up
- Generated demo evidence for health, model info, predictions, metrics, OpenAPI, CLI output, training metrics, baselines, backtests, monitoring, error analysis, and robustness scorecards.
- Documented limitations around closed-loop evaluation cost, in-memory serving caches, fallback modes, and lack of realized online accuracy against live outcomes.
How I would present it
I would start with the feature contract and per-target artifacts, then show the API checks and docs/assets evidence pack.
The honest boundary is that monitoring artifacts prove scheduled drift/retrain checks, not realized online accuracy from production traffic. For the fastest public recruiter link, the README points to deploying the Streamlit dashboard first and the FastAPI service afterward.
Proof
VerifyRepository, checks, stack, status
- 01
Open the GitHub repo.
- 02
Read the architecture and edge-case sections.
- 03
Follow the documented proof path: README, docs/assets, feature contract, backtests, API artifacts.
- Role
- Data joins, feature engineering, model training, backtests, serving
- Scope
- Forecasting system for energy consumption and production
- Proof
- README, docs/assets, feature contract, backtests, API artifacts
- Stack
- Python, Pandas, LightGBM, FastAPI, MLflow, Prometheus, Docker
- Rows
- 2.0M+
- Contracts
- Strict
- Targets
- 2 models
- Serving
- API + CLI