Case study 01 · Forecasting infrastructure
From raw data to trusted forecasts.
Building a configurable data platform that ingests operational history, makes it model-ready, evaluates forecast quality, runs cloud-native prediction, and returns usable results to the systems where work already happens.
Configuration / ForecastProduction interface
01 / Context
Forecasting is a systems problem before it is a model problem.
The model sits in the middle of a much longer chain. Every weak handoff around it reduces trust in the output.
Historical sales existed across ERPNext, uploaded files, AWS S3, and BigQuery. Turning that history into a dependable forecast required more than calling a model.
The platform needed to detect changed inputs, normalize inconsistent schemas, create continuous time series, isolate heavy ML workloads from the application server, evaluate forecasts before production use, and write results back without overlapping jobs or silent failures.
02 / Constraints
Four risks shaped the design.
The architecture was designed around the ways a real forecasting workflow can become expensive, unreliable, or unusable.
Fragmented inputs
Different sources, column names, file versions, frequencies, and history windows had to converge safely.
Heavy computation
Deep-learning training could not be allowed to consume the Frappe application server or block web workers.
Unknown quality
A production forecast needed objective backtesting—not confidence based only on a successful model run.
Operational failure
Duplicate jobs, stale locks, partial writes, missing logs, and orphaned compute all needed explicit safeguards.
03 / Architecture
A modular path from input to action.
Frappe acts as the control plane; cloud services perform storage, warehouse transformation, and forecast computation.
End-to-end production flow
01ERPNext / S3 / FilesHistoric operational data
02Frappe orchestratorConfiguration, queue, and cache lock
03Validate & transformMapping, cleaning, and aggregation
04Cloud storageS3 and BigQuery tables
05Forecast computeEphemeral GCP VM or BigQuery AI
06Evaluate & storeMetrics, quantiles, and outputs
07DeliverERPNext, BigQuery, S3, and APIs
Control plane: Frappe background jobs + centralized loggingData plane: S3 + BigQuery + on-demand compute
04 / Compute strategy
Two execution paths. One operating model.
The system supports configurable model training and a warehouse-native foundation-model pipeline without forcing one tool onto every workload.
AutoGluon on ephemeral GCP.
Frappe provisions a Compute Engine instance, injects a generated startup script, pulls historical data from S3, trains the selected model, uploads forecasts, and terminates the VM after completion.
- AutoARIMA, AutoETS, DeepAR, and Temporal Fusion Transformer options
- Configurable presets, hyperparameters, horizon, and quantiles
- Heavy work isolated from the application server
- Self-termination limits idle infrastructure cost
TimesFM 2.5 inside BigQuery.
Python remains the orchestrator while SQL transformations and forecasting run where the data already lives. BigQuery AI.FORECAST uses TimesFM 2.5 with up to 2,048 historical observations in the documented configuration.
- No locally executed forecasting model
- Atomic ingestion and warehouse-native transformations
- Automated 60-day holdout evaluation
- Production output written to a dedicated forecast table
05 / Pipeline
Reliability at every stage.
Each stage leaves behind a useful, inspectable dataset instead of hiding the whole workflow inside one opaque job.
Ingest incrementally
Compare source metadata to detect new or modified S3 files, read CSVs in chunks, apply configurable mappings, and commit only validated staging data.
Build a continuous series
Aggregate transactions into daily demand and fill missing feature/date combinations with zero, preserving the continuity forecasting models require.
Profile feature behavior
Materialize first and last sale dates, active and inactive days, total sales, daily averages, and activity ratio—then classify demand as A, B, or C.
Backtest before production
Remove the latest 60 days, forecast that holdout, compare predictions with actuals in weekly windows, and store multiple quality signals per feature.
Forecast and deliver
Run production forecasting on complete history, store the output, then sync median and confidence values to ERPNext, BigQuery, S3, or API consumers.
06 / Evaluation
A forecast should explain how wrong it might be.
The pipeline stores complementary measures because no single metric describes every kind of demand behavior.
Average distance between the forecast and actual demand.
Weights larger misses more heavily than smaller ones.
Shows systematic over-forecasting or under-forecasting.
Calculated only where actual demand is greater than zero.
More robust than MAPE for lower-volume products.
Compares total predicted demand with total actual demand.
Compares forecast and actual averages across the period.
Measures how closely the forecast follows demand movement.
07 / Operations
Safe to run repeatedly.
The less visible parts—locks, logs, cleanup, and cost boundaries—are what make the platform production-ready.
Operational safeguards, designed in.
Frappe’s long queue prevents web-worker lockups. Cache locks stop duplicate pipelines. A dedicated DeepMatrix Log records progress, API calls, warnings, and failures. Locks are released on completion, and ephemeral VMs self-terminate.
Documented BigQuery estimate
$0.50–$1.70
Estimated weekly pipeline cost at roughly 2,215 products and 4.5 million observations.
Estimate—not measured spend. Actual cost varies by growth, region, forecast horizon, and current Google Cloud pricing.
08 / Interface
Complex infrastructure, controlled from one place.
The Frappe Configuration DocType exposes source mappings, model settings, cloud configuration, export destinations, anomaly monitoring, and logs.
The central idea
A useful forecast is not a file. It is a reliable operating loop.