From a Timestamped DataFrame to a Forecast
The public Kronos predictor turns the architecture into a concrete interface: a pandas DataFrame supplies historical market values, timestamp series define the observed and future intervals, and a forecast DataFrame comes back in the original feature space. The important question is what happens between those two objects. Following that path clarifies the predictor's input contract, the meaning of its normalization, the cost and purpose of sampled paths, and the difference between a bad input alignment and a genuinely weak model forecast.
What the predictor expects from the data
A valid single-series request begins with a DataFrame containing open, high, low, and close. Volume and amount are supported but optional. If volume is absent, the public predictor fills both volume and amount with zeros. If volume is present but amount is absent, it derives amount from volume multiplied by the row's mean price across the required price fields. These rules make the interface tolerant of incomplete auxiliary data, but they do not recreate the missing measurement. A zero-filled volume channel means “the caller supplied no volume,” not “the market definitely traded zero units.”
The distinction matters because the model was trained to use the six-channel representation while the predictor can operate with less information. The fallback keeps the tensor shape consistent and allows price-only use cases, but it changes the evidence available to the model. A forecast made with observed volume and a forecast made with a zero-filled volume channel should not be interpreted as equivalent experiments simply because both return six columns.
The required price columns must contain usable numeric values. The predictor checks the modeled price and auxiliary channels for missing values and raises an error when it finds NaNs. This is preferable to silently turning an unknown price into a model input, because an imputed price would change the historical context and could affect every generated step. The API's validation is therefore part of the model boundary: it decides which malformed or incomplete inputs are rejected before tokenization begins.
The timestamps have their own contract. Historical timestamps must align with the rows of the DataFrame, and future timestamps must describe the requested prediction horizon. Kronos extracts minute, hour, weekday, day, and month from these values and feeds them as temporal features. A timestamp with the wrong frequency or an offset row can therefore do more than mislabel the output index; it can give the model a calendar context that does not match the numerical sequence.
The public interface keeps historical and future time arrays separate. The historical series describes the context supplied to the model. The future series describes the periods for which decoded rows will be returned. The requested prediction length must agree with the future timestamp length. These relationships are easy to break when a DataFrame is sliced by position while timestamps are sliced by a different index. Such a mismatch is an input failure, not evidence that Kronos cannot forecast the asset.
Once the schema and lengths are valid, the predictor extracts the six modeled channels in a fixed order and computes a mean and standard deviation for each channel over the historical window.