Planners need a forecast service, not a model artefact

A forecasting service needs a usable answer when its preferred candidate cannot be trusted. That answer may be the frozen analogue prior before launch, a naive or attribute baseline after observations arrive, or a previous approved release whose evidence conditions remain valid. The fallback is selected during release design, not improvised after an incident. It runs in the same evaluation and uses the same demand contract so that reversion does not introduce a new target or grain.

Rollback conditions cover evidence, model and decision health. Failed identity checks, unavailable critical features, expired calibration, invalid quantiles, excessive latency and breached performance expectations can all make a candidate ineligible. The service records which condition fired, which baseline took over and which planning decisions were affected. Operational monitoring guidance explicitly includes rollback among the responses to unexpected data or model performance.[S40]

A fallback must be tested while conditions are normal. The team rehearses the technical switch, checks that planners can recognise the active baseline and confirms that downstream scenario sheets still reconcile. It also verifies that the baseline's own assumptions remain valid. Returning to an obsolete prior is not a safe outcome merely because the prior is simple. The fallback register therefore carries freshness, eligibility and expiry rules as well.

A candidate does not return automatically when a technical fault disappears. Re-entry requires the cause to be classified, the correction to be validated and the release gate to be repeated on the appropriate launches. If drift caused the incident, the review asks whether the reference population, features or target definition changed. If calibration failed, it tests the replacement calibration on evidence that was not used to fit it. If the operating burden caused missed deadlines, it reassesses whether the candidate belongs in production at all.

This discipline limits technical debt. Research on machine-learning systems warns that a small accuracy benefit can be unwise when it requires a large increase in system complexity.[S39] A fallback that depends on another fragile chain of corrections may preserve mathematical sophistication while weakening operational control. The preferred baseline is the simplest approved forecast that supports the decision reliably under the current evidence.

Rollback is consequently not an admission that the forecasting programme has failed. It is evidence that the programme can contain failure. A service that never needs reversion may be operating in stable conditions, or it may be unable to recognise deterioration. Recording and reviewing fallback events makes that distinction testable and gives planners a reason to trust the release mechanism rather than any individual model.

The build-against-buy decision concerns components, not sovereignty over the whole forecasting problem. Commodity storage, orchestration or managed inference may be purchased when they reduce operating work. The demand definitions, event history, availability record, release register and evaluation evidence must remain portable and inspectable. A vendor can supply a model endpoint without owning the meaning of the venture's demand or the authority to approve its production plan.

Vendor assessment starts with the exact service boundary. The register lists fields sent, transformations applied, hosting and retention arrangements, model and configuration identifiers, monitoring access and the outputs returned. It also records licence and support terms, revision policy and the ability to export features, forecasts and logs. Legal and contractual terms require the appropriate professional review; the technical register makes that review concrete rather than implying legal clearance.

Reproducibility is the decisive exit test. The team should be able to take a historical release manifest and its exported evidence, run the approved baseline elsewhere and reproduce a usable planning package. It should also test what happens when the external service is unavailable, a model version changes or a required export is incomplete. Monitoring and rollback controls are meaningful only if the organisation can inspect their signals and act on them through an alternative route.[S40]

A low headline inference price can coexist with expensive integration, correction and supervision. The comparison therefore includes data preparation, availability capture, calibration, launch replay, planner training, incident handling, version review and exit work. It also includes the opportunity cost of maintaining features that do not improve decisions. Technical-debt research supports rejecting a tiny accuracy benefit when its system-complexity cost is disproportionate.[S39]

The review is repeated when the service or the venture changes. A new channel may alter the data contract. A vendor revision may change output under the same product name. A growing launch corpus may make an owned global model practical, or it may confirm that a simpler purchased component remains sufficient. Neither building nor buying is a permanent virtue. The approved configuration is the one that preserves evidence ownership, planning value and a tested exit under current conditions.

GFT's practical default is consequently proportionate: buy commodity capability where it is demonstrably useful, keep the demand record and release controls under the venture's authority, and require every candidate to leave a reproducible trail. The service is complete when planners can understand a release, challenge it, act within their constraints and continue safely without the preferred model. Anything less is a model artefact with a planning interface attached.