Key Concepts
pd4castr is a platform for publishing, running, and viewing containerised forecasting models. Before you start building, it helps to understand the core concepts that make up the system.
Models
A model is a containerised application that runs inside Docker. This could be anything from a machine learning model to a statistical forecasting script or a simulation engine. It consumes input data, executes your forecasting logic, and produces structured output. You define your model as a Docker image with a configuration file that describes its inputs, outputs, and behavior.
Model groups and revisions
Models are organised into model groups. Each time you publish a new version of a model, pd4castr creates a new revision within the same group (r0, r1, r2, and so on). This lets you iterate on your model while keeping a clear version history. Consumers of your model always see the latest revision by default.
Inputs
Inputs are the data files your model consumes during a run. There are two source types:
- Static inputs — files you upload manually as part of your model project (for example, reference data or lookup tables).
- Fetched inputs — data pulled automatically from external databases. The platform connects to your data source and fetches new data on a schedule you configure. Contact us to connect your database
Each input has a key that your model uses to identify and read the file at
runtime.
Outputs
Outputs are the forecast data your model produces. You define typed columns
(such as float, date, string, or integer) in your configuration file.
Outputs can also include series keys — columns that categorise your forecast
data, for example by region or product category.
Sensitivities
Sensitivities let you run “what if” scenarios against your model. Each sensitivity defines a SQL query that transforms the input data before the model runs. This lets you explore how changes to assumptions affect your forecast without modifying the model itself. For example, you might create a sensitivity that increases a key input value by 10% to test your model’s response to changing assumptions.
Input aggregations
Input aggregations are SQL-derived summary views of your input data. They display alongside forecast output in the platform, giving viewers additional context about the data your model consumed. For example, you might aggregate raw input data into logical sums.
Time horizons
Every model is categorised by the time period it forecasts:
| Time horizon | Description |
|---|---|
| Day Ahead | Forecasts for the next day |
| Week Ahead | Forecasts for the coming week |
| Quarterly | Forecasts spanning a quarter |
| Historical | Retrospective analysis of historical data |
The time horizon you choose determines how your model appears in the platform and how viewers navigate to it.
Forecast variables
A forecast variable describes what your model predicts, for example, price. Each model is associated with a forecast variable that determines how its output is labelled and displayed in the platform.
Run modes
Run modes control when your model executes:
- Automatic — the model runs automatically whenever new input data arrives from a configured data fetcher. This is the typical mode for production models.
- On demand — the model runs only when a user manually triggers it from the platform. This is useful for ad-hoc analysis or models that don’t need to run on a schedule.
Model lifecycle
When a model run is triggered, it moves through a series of stages:
- Pending — the run has been created and is waiting to start.
- Input files prepared — the platform has gathered all required input data.
- Running — the model container is executing.
- Completed or Failed — the run finished successfully, or an error occurred during execution.
You can monitor run status from the platform dashboard.
Next steps
Now that you understand the building blocks, head to the Quick Start to publish your first model.