Skip to content

Time-Series Forecasting & Lag Features Guide

Time-series forecasting models differ from classification or regression models. Instead of making predictions from isolated data points, time-series models learn trends and seasonal patterns from sequences of historical observations.

1. The Challenge of Online Time-Series Inference

During AutoML training, PowerMind InsightML automatically creates:

  • Lag Features: target values at prior steps. The platform automatically determines which lags to compute based on the length of your dataset:
    • Always Computed (Length >= 20): lag_1, lag_2, lag_3, and lag_7.
    • Medium Datasets (Length >= 70): Adds lag_14.
    • Large Datasets (Length >= 150): Adds lag_30.
  • Rolling Statistics: Rolling mean and standard deviation windows calculated over shifted targets:
    • rolling_mean_3, rolling_std_3 (3-step window)
    • rolling_mean_7, rolling_std_7 (7-step window)
    • rolling_mean_14, rolling_std_14 (14-step window)
  • Temporal Features: Day of month (day), month (month), day of week (dayofweek), and week of year (weekofyear).

To generate a prediction, the deployed model requires these same engineered features. However, real-time prediction servers evaluate only one row at a time. The serving runtime does not maintain state, meaning it cannot calculate rolling averages or lags from a single input vector.

Incoming Stream:
[Day t-6, Day t-5, Day t-4, Day t-3, Day t-2, Day t-1, Day t]
                               |
                      [Lag Engine Sync]
                               |
             Predict Day t+1 (using context history)

2. The Solution: Managed Lag Computation

InsightML solves this challenge by providing a managed Lag Computation Service. Rather than manually writing complex feature calculation scripts, you can send raw historical observations to the platform's lag endpoint. The platform processes the history and returns a payload formatted for the inference service.

This workflow is illustrated in the diagram below:

SLIDING WINDOW LAG COMPUTATION FLOW 1. Historical Observations (7-30+ rows) t-6 t-5 t-4 t-3 t-2 t-1 t Target column values and timestamps are sorted chronologically by the system. 2. Lag Engine 🔄 Computes Rolling & Lags Generates formatted Triton-ready payload 3. Serving Model 🔮 Forecast Day t+1 (Triton prediction result)

Custom Pre-built Lag Features (Opting Out of Auto-Lags)

If you already pre-built lag/rolling features in your source dataset, you can opt out of the platform's automatic lag generation:

  1. When training, set auto_create_lags to false (via API payload, SDK parameter, or the UI dropdown).
  2. Under this configuration, the model is trained exactly on the features provided in the training file.
  3. At deployment time, inference_requirements in the deployment metadata will be null / none, and the console's Time-Series Inference Helper panel will be hidden.
  4. During online inference, you do not need to call the lag computation service. Simply construct and send the inference inputs directly to /infer/{deployment_name} with all pre-computed features already populated in the request payload.

3. End-to-End Time-Series Inference Workflow

Step 1: Verify Deployment Information

Query the deployment details to verify the target column, time column, and features configuration: 

deployment = client.get_deployment(deployment_id=4)
metadata = deployment["metadata"]

# The system flags time-series requirements in the metadata
requirements = metadata.get("inference_requirements")
print("Requirements:", requirements)
# Returns: {'type': 'time_series_with_lags', 'lag_features': ['lag_1', 'lag_2', ...]}

Step 2: Format Historical Observations

Prepare a chronological list of dictionaries representing the target values. For example, if you forecast sales, gather observations from the last 7 to 30 days: 

historical_observations = [
    {"timestamp_col": "2026-06-01", "sales_volume": 120.5},
    {"timestamp_col": "2026-06-02", "sales_volume": 128.0},
    {"timestamp_col": "2026-06-03", "sales_volume": 135.2},
    {"timestamp_col": "2026-06-04", "sales_volume": 110.1},
    {"timestamp_col": "2026-06-05", "sales_volume": 142.0},
    {"timestamp_col": "2026-06-06", "sales_volume": 150.3},
    {"timestamp_col": "2026-06-07", "sales_volume": 161.4},
]

Step 3: Request Lag Calculation

Invoke compute_deployment_lags on the platform. The platform handles chronological sorting, fills any missing records, calculates lags, and constructs the Triton inference payload: 

lag_payload = client.compute_deployment_lags(
    deployment_id=4,
    historical_data=historical_observations,
    target_column="sales_volume",
    time_column="timestamp_col"
)

# Extract computed feature values
features = lag_payload["features"]
print("Computed rolling mean (3 steps):", features["rolling_mean_3"])

# Extract the ready-to-use Triton prediction input payload
prediction_input = lag_payload["triton_payload"]["inputs"]
print("Triton Payload:", prediction_input)

Step 4: Run Inference

Pass the computed triton_payload directly to the infer() method using your deployment prediction key: 

client.set_deployment_api_key("IML_live_deploy_production_key_here")

result = client.infer(
    deployment_name="xgboost_ts_v1",
    inputs=prediction_input
)

forecasted_value = result["outputs"][0]["data"][0]
print(f"Forecasted sales volume for next step: {forecasted_value}")

4. Minimum Data Guidelines

To prevent errors when calling the lag calculator:

  1. Row Count: The length of the historical data array must be greater than or equal to the largest lag parameter (typically at least 7 rows, though 30+ rows are recommended to calculate rolling metrics like rolling_std_14).
  2. No Gaps: Timestamps must be sequential. Ensure data does not contain null entries in the target column.
  3. Correct Scopes: The lag computation endpoint requires Platform API Key or JWT session auth since it accesses historical workspace variables. The inference endpoint requires the Deployment API Key.