Update forecast state without rewriting history

Exponential smoothing gives an inspectable example: a fixed coefficient mixes the new value with the old level. Updating that level is not the same operation as choosing a new coefficient from a longer training sample. State-space filters make a similar distinction between filtering with fixed model parameters and refitting them. The statsmodels 0.14.4 forecasting example explicitly separates extending a result under existing parameters from appending with parameter re-estimation. Name both actions in the service’s lifecycle and logs.

Version state against the exact model and transformation artifact that produced it. Hidden state computed under one recurrent network’s weights is not generally valid under another network after promotion. A new model may require replaying a warm-up history, converting a state through a justified migration, or beginning in a documented cold state. Evaluate that transition in backtests. Otherwise a deployment can introduce prediction discontinuities that never appeared in evaluation because the notebook silently initialized every model from complete history.

Give observations stable logical identities and monotonic version rules. If the same accepted version is redelivered, deduplicate it before advancing state. Applying the smoothing update twice treats one measurement as two sequential observations and changes the level incorrectly. A corrected value for an earlier timestamp is a replacement in the logical history. Restore a checkpoint preceding that point and replay accepted observations, or use a proven model-specific correction formula when its assumptions truly hold.

For fixed-coefficient smoothing with no intervening structural changes, a correction’s contribution decays geometrically through subsequent accepted updates. This makes a useful reference oracle. It does not apply unchanged after a parameter refit, nonlinear clipping, missing-value policy change, or insertion that shifts the sequence of observations. Late events require a declared ordering policy. Event-time reordering with replay, bounded-lateness rejection, and correction-only scoring are different products and should not be mixed implicitly in one mutable state path.

Checkpoint the model identity, feature-definition identity, state schema, accepted input position, logical revision state, and numerical state together. If state commits without its offset, replay can double-apply inputs; if the offset commits first, recovery can skip updates. Use a transactional boundary or an idempotent recovery design that makes this relationship explicit. A message broker’s delivery guarantee alone does not prove the forecasting state is correct across application failures and external storage writes.

Preserve issued forecasts as immutable decision records even when later truth corrects the historical state. New forecasts should use the corrected replayed state according to policy, while earlier forecasts remain evidence of what was actually served. Monitor state age, replay backlog, duplicate suppression, revision frequency, and model-state compatibility failures. A state checksum can detect byte changes but cannot establish that the correct logical history was consumed; validate recovery by replaying a known fixture and comparing forecast outputs and input positions.