Attribution

The Reverse Fork

Outcome → Scenario · The Forecast, Run Backwards

The forward Fork asks what could happen — the ensemble split into scenario branches, each with a probability. The Reverse Fork asks the opposite question: now that the atmosphere has answered, which branch was it verifying toward? We take an earlier run's scenario branches (their member share at issue is the prior), weigh each branch's centroid against the verifying analysis (the evidence), and apply Bayes to get the posterior — the outcome-conditioned scenario map of the method. Full board: Verification ▸

How to read this

The math. For the newest run whose Day-7 valid time has passed, the 50 ECMWF-EPS members are k-means-clustered into scenario branches. Each branch's prior is its member share at issue — the weight the ensemble itself gave that future. The evidence is the verifying analysis: each branch-centroid's anomaly correlation against it, standardized across branches, plus a bonus when a branch's regime label matches the verifying flow. Bayes then reallocates the mass — P(branch | analysis) ∝ π · exp(β·z + γ·match). Evidence that fits every branch equally leaves the prior untouched; evidence that singles one out concentrates on it.

The honesty rules. This is the retrospective Reverse Fork: attribution after verification, association not causation. It never claims the winning branch was prospectively identifiable — the prior column is exactly what the ensemble believed at issue, frozen. The spec's full pathway attribution (sequences of branches across runs), per-lead evidence and trigger/kill conditions await per-lead cluster artifacts.