Learning TFT: what was actually known when a forecast was issued?

01 / Fix the prediction question first

At an origin t, predict a named outcome at t+h. The unit might be a province and the target a documented risk indicator. That statement needs an issue date, horizon, target definition and available input history. An annual risk assessment with contemporaneous variables is not automatically a prospective forecast.

The supplied abstract mentions TFT–GNN, but does not give its forecasting horizon or target construction. The examples here explain questions to ask when reading or implementing TFT; they do not fill in those missing manuscript details.

02 / Three input families, two timestamps

Static context describes an entity; observed inputs become known through measurement; known-future inputs are available for a future target time before the forecast is issued. Each field needs both the period it describes and the date its value became available.

• A future calendar year or scheduled event can be known. Realized rainfall next year cannot be treated as known-future rainfall. A weather forecast is a different, vintage-specific input.
• A statistic for 2015 revised in 2018 is unavailable to a forecast issued in 2016. Historical validity is not the same as historical availability.
• Static does not mean timeless: a topology or installed-capacity category may change. Version it at the forecast origin when necessary.

03 / Read the TFT components by their job

The original TFT combines variable selection, static-covariate context, recurrent processing for local temporal structure, attention for longer dependencies and gating/residual mechanisms. Its multi-horizon quantile outputs answer a different question from a single deterministic score.

Start with a seasonal or persistence baseline and a simpler model using the same information. Compare errors by horizon, region and extreme-event subset. A large architecture alone is not evidence that a small panel needs it.

04 / Hand-check the asymmetric loss

For residual e = y − q̂, pinball loss is max(τe, (τ−1)e). At τ=0.9, underpredicting by 2 costs 1.8; overpredicting by 2 costs 0.2. For y=[10,20] and predictions [12,18], the mean loss is 1.0.

A nominal 10th–90th percentile interval targets 80% coverage; it does not guarantee it. Measure empirical coverage and interval width on held-out cases, check quantile crossing, and inspect regional coverage rather than treating a narrow interval as proof of reliability.

from climate_protocol import pinball_loss

loss = pinball_loss([10, 20], [12, 18], 0.9)
assert abs(loss - 1.0) < 1e-12

05 / Run a small information-boundary check

From the repository root, run the commands below with Python 3.8 or later. No GPU, PyTorch or model weights are needed. The import snippet above can be run from notebook/examples. Expected availability outputs are true, false, false for the future calendar, future observed rainfall and late historical revision.

python notebook/examples/climate_protocol.py
python -m unittest discover -s notebook/examples -p test_climate_protocol.py -v

06 / A useful reading habit

Before comparing attention plots, write an availability ledger. Ask which input would disappear if the forecast were replayed at its original issue time. Variable-selection and attention weights can describe model behavior, but they are not causal effects or automatically stable explanations.

These checks validate loss arithmetic and information rules only. No TFT training or manuscript performance is evaluated here.