---
id: VOLT-HOME-WP-059
title: "How serving-lineage controls prevent forecast survivorship bias"
slug: how-serving-lineage-controls-prevent-forecast-survivorship-bias
description: "An audit of how exact zone-date-horizon-model lineage limits live-service evidence to forecasts that were actually selected before outcomes were known."
published: 2026-08-30
cluster: "Forecast verification and uncertainty"
status: measured
evidence: /research-data/home-papers/how-serving-lineage-controls-prevent-forecast-survivorship-bias.json
figure: /research-media/home-papers/how-serving-lineage-controls-prevent-forecast-survivorship-bias.webp
figure_alt: "Chart for How serving-lineage controls prevent forecast survivorship bias: accuracy rows exactly matched to a serving-lineage decision, shown as not matched, matched."
source_ids:
  - volt-promotion-policy
  - volt-v61-card
  - volt-research-content
  - google-article
  - entsoe-sdac
peer_reviewed: false
---

## Abstract

Serving lineage prevents survivorship bias by requiring a scored forecast to match the model version selected before the delivery outcome was known. In the frozen audit, 14.578097537738794% of 121758 scored accuracy rows exactly match an immutable serving-lineage decision. The match key includes bidding zone, delivery date, horizon bucket, and served model version.

The low match share is not repaired by choosing another archived model. Unmatched scores can remain useful as development, backtest, shadow, or forensic evidence, but they are not live-service evidence under this contract. The control preserves losses as well as wins: if the recorded serving model performed poorly, its score remains eligible; if an unserved model performed better in hindsight, it cannot replace the served version. Objective-specific governance also stops a point-only benchmark challenger or a failed development model from being presented as the customer quantile service. This paper describes the control and its measured coverage; it does not claim that every unmatched row is defective.

## Plain-language answer

Without lineage, an analyst can look back after prices are known, find the model version that happened to perform best, and describe that score as if users had received it. Serving lineage blocks that move. A score counts as live-service evidence only if the database already records that exact version as served for the same zone, delivery date, and horizon.

The audit shows why the distinction is material. The accuracy table contains 121758 scored rows: 17750 exactly match a serving decision and 104008 do not, so the matched share is 14.578097537738794%. The rest should not disappear; they should be labeled according to their actual role. Keeping them visible while excluding them from live claims avoids both cherry-picking and erasure of development history.

## Research question

The question is how a data contract can stop forecast survivorship bias. Survivorship bias here means selecting models or scores conditional on outcomes and then presenting the survivors as if they had been the ex ante service. The relevant counterfactual is not “which archived model would we now prefer?” It is “which version had already been selected when the forecast was issued?”

The implemented audit measures the share of all scored rows that have an exact serving-lineage match. It does not compare the accuracy of matched and unmatched rows, because that comparison could mix models with different objectives and states. ENTSO-E's [Single Day-ahead Coupling (SDAC)](https://www.entsoe.eu/network_codes/cacm/implementation/sdac/) provides context for the day-ahead targets. It does not identify which Voltcast model was served; only the immutable internal lineage contract can do that.

## Data and provenance

The evidence JSON at the frontmatter URL is frozen at `2026-08-30T00:00:00Z`. The family contracts are `forecast_accuracy`, `forecast_serving_lineage`, `risk_accuracy`, `generation_mix`, and `zone_temp_weighted`. This audit uses every `forecast_accuracy` row with non-null MAE and tests whether `forecast_serving_lineage` contains an exact corresponding decision.

The join keys are zone ID, delivery date, horizon bucket, and model version, where the scored `model_version` must equal `served_model_version`. A match does not depend on whether the score is good. The aggregate extraction was SELECT-only and read-only with a 180-second statement timeout.

Snapshot SHA-256 is `7e97489fc8528c8cc8c38830e05b48d949ce1f67b98575dff26f5d7c321e4c67`. Analysis-code, protocol, registry, and source-registry hashes are `57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9`, `adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b`, `7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717`, and `07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6`. The evidence and figure hashes are `ed72f619f9ad3ab53a75299c31b01a1ab85ce594ff7452d733b37f4c77744155` and `38006d00086e8c3989e0d8b3927eb13d401b5a9831183304988b26d9ff3fffd2`.

## Method

The extractor left-joins scored accuracy to serving lineage on the full decision identity. It marks a row `lineage_matched` when the joined lineage record exists. The analysis retains all scored rows with non-null MAE, counts exact matches, divides that count by the total, and reports the share as a percentage. The sample size is the 121758 scored rows inspected.

The control is complemented by [Objective-specific seven-day forecast promotion](https://github.com/ossedk/voltcast/blob/main/docs/voltcast/OBJECTIVE-PROMOTION-POLICY.md). Point, quantile, external-challenger, and production-main policies represent different output contracts. A version can be legitimate evidence for one objective without being the serving champion for another. The [Volt 6.1 cross-zone price model card](https://github.com/ossedk/voltcast/blob/main/docs/voltcast/V6.1-MODEL-CARD.md) provides a concrete governance case: Volt 6.1 generated development evidence, failed its registered gate, and never served. Its historical proxy scores cannot be transformed into live-service evidence by retrospective preference.

## Results

Exactly matched serving-lineage rows account for 14.578097537738794% of 121758 scored rows. In counts, the figure shows 17750 matched and 104008 unmatched rows. The result quantifies the fraction eligible for live-service claims under the exact join. It does not assert that the unmatched remainder is useless or erroneous. It asserts that those rows lack the decision identity required for this specific claim type.

The regenerated evidence records `bootstrap_95_interval` as null and the interval method as “not reported for this estimand.” No uncertainty interval accompanies the 14.578097537738794% match share.

No accuracy difference between matched and unmatched rows is reported. No current champion is named. No model is promoted or demoted by this audit.

## Robustness and placebo checks

The full-key match is the main robustness control. A partial match on zone and date would be inadequate because multiple horizons and model versions can coexist. Exact model equality blocks an analyst from assigning a better-scoring sibling version to the serving decision. Retaining unmatched rows in the denominator makes coverage gaps visible rather than silently dropping them.

Objective separation acts as a semantic placebo check: a point challenger should fail a query that asks whether it served a probabilistic production contract unless the appropriate lineage decision exists. A failed development programme should also remain unmatched for live service. These are contract implications; the public evidence does not publish separate placebo counts for them.

The registered family refers to blocked uncertainty intervals for inferential claims, but this binary audit reports none. Rows sharing dates or related horizons are dependent, and that dependence is not quantified. No unadjusted significance claim or Holm-adjusted discovery is made.

## Limitations

A missing match can have several causes: a row may be backtest evidence, shadow evidence, a non-serving model score, or a date before complete lineage recording. The public aggregate does not classify those reasons. It would be wrong to label every unmatched row as invalid.

An existing lineage row proves the recorded selection identity, not every aspect of issuance integrity. A stronger receipt could also bind issue timestamp, curve hash, source-run hashes, completeness, and publication destination. Those fields are outside the paper-level match statistic.

The percentage pools zones, horizons, dates, and versions. Coverage may be complete in a recent period and sparse historically. The result does not estimate bias magnitude; it measures exposure to ambiguous attribution. Finally, the ordinary bootstrap does not preserve clustered dates and horizons.

Lineage also cannot correct a bad decision merely by recording it. If a promotion gate was weak, the immutable record will faithfully identify the chosen version while the score may still disappoint. That is a feature of the audit: selection quality and selection honesty are separate questions. The former requires proper prospective gates and controls; the latter requires a durable receipt. This paper measures only the availability of that receipt for scored rows.

There may also be legitimate duplicate scores for one target under different research objectives. Exact lineage prevents those rows from collapsing into one live claim, but the paper-level aggregate does not enumerate objective identities. A complete audit should report them explicitly.

## Practical implication

Public accuracy claims should default to the matched subset and label everything else. A model leaderboard can still show development and shadow scores, but it must not average them into a live-service badge. This makes poor serving outcomes harder to hide and attractive unserved outcomes harder to appropriate.

For households, lineage means an accuracy statement can be traced to the model and horizon that actually produced the curve used by the service. For operators, the 14.578097537738794% match share identifies a documentation and receipt-coverage problem, not an invitation to loosen the definition. The [Voltcast Research Content Plan](https://github.com/ossedk/voltcast/blob/main/docs/voltcast/RESEARCH-CONTENT-PLAN.md) requires every number to remain bound to its source and losses to remain visible.

## Reproducibility

Verify the evidence file and manifest hash, then verify snapshot, analysis-code, protocol, and registry hashes. Select scored accuracy rows with non-null MAE. Left-join serving lineage on zone ID, delivery date, horizon bucket, and equality between scored and served model version. Convert join existence to a binary indicator, sum matches, divide by all scored rows, and express the point estimate in the declared percent unit.

A follow-up should classify unmatched reasons, report coverage by date, zone, horizon, and objective, and bind curve and source hashes. It should preserve the strict definition rather than backfill favorable scores. Google Search Central's assigned [Article structured data](https://developers.google.com/search/docs/appearance/structured-data/article) guidance supports machine-readable title, date, image, and evidence identity on the public page; publication markup does not substitute for model lineage.

## Disclosure

Analysis and drafting were model-assisted. The model explained the frozen lineage audit and did not choose surviving model results. Sources, method, assumptions, limitations, and evidence hashes are disclosed. This working paper is not peer reviewed.

Volt has zero live traders and zero live capital. C0R is the only paper strategy. Production forecasting is a non-trading service. Serving-lineage governance does not authorize trading, capital, or model promotion. This paper is not trading advice or financial advice and contains no measured customer-savings claim.

## References

1. Voltcast. “Objective-specific seven-day forecast promotion.” https://github.com/ossedk/voltcast/blob/main/docs/voltcast/OBJECTIVE-PROMOTION-POLICY.md
2. Voltcast. “Volt 6.1 cross-zone price model card.” https://github.com/ossedk/voltcast/blob/main/docs/voltcast/V6.1-MODEL-CARD.md
3. Voltcast. “Voltcast Research Content Plan.” https://github.com/ossedk/voltcast/blob/main/docs/voltcast/RESEARCH-CONTENT-PLAN.md
4. Google Search Central. “Article structured data.” https://developers.google.com/search/docs/appearance/structured-data/article
5. ENTSO-E. “Single Day-ahead Coupling (SDAC).” https://www.entsoe.eu/network_codes/cacm/implementation/sdac/