Bayesian eligibility

When the posterior publishes, degrades, refuses or raises

The Bayesian posterior publishes a number only when it has the readings the blend needs. Every other subject stays in the result with the reason it was refused. The rules shared by both method families are on Choose a method.

Where the gate sits

BayesianPosterior calls assess_eligibility on the prepared subjects before any precision is computed. Only a subject that passes reaches the blend \(\hat\theta = w_0\mu_0 + w_M x_M + w_C x_C\). Symbols follow the notation page.

The checks, in order

The first check that matches names the reason. The codes are the values of PosteriorReason.

  1. missing_input: The previous actual \(y_{t-1}\) is absent, not finite or zero, so there is no growth base; or the consensus is not finite.
  2. insufficient_history: Too few realised growth observations for the prior, or prior statistics that are not valid.
  3. no_consensus_precision: Neither analyst dispersion nor the consensus error history gives a precision \(\tau_C\).
  4. missing_prediction: The model is included but its value is absent or not finite.
  5. nonfinite_result: The blend or the interval came out not finite, after every input passed.

Degrading is not refusing

A model value whose error record is too short to give a precision \(\tau_M\) drops out of the blend. The subject is still published on the prior and consensus, with an interval, and the model’s precision and weight stay missing. A missing model value is different: that is missing_prediction, and the subject is refused.

What the posterior does not check

The anchored family refuses stale inputs and very wide gaps. The posterior does neither, so these are the caller’s policy:

  • Input age: No maximum age is enforced. The prepared age columns let the caller refuse stale inputs before publishing.
  • Gap to consensus: No gap is too wide. A model far from consensus is weighed by its precision, not refused.
  • Revisions: Preparation reads the latest actual known at the cutoff. A first-release policy has to be applied before preparation.

The panel workflow’s reasons

bayesian_kpi_predictions prepares and reads the panel itself, including publication-relative reads, so its reasons describe the read as well as the blend. They are its own vocabulary, not PosteriorReason codes.

  • eligible: Published.
  • previous_actual_unavailable: The read falls before the previous period’s actual could be published, so there is no growth base yet.
  • history_not_yet_available: The history the estimate needs was reported after the read moment.
  • insufficient_inputs_or_history: The read succeeded, but the inputs or the history were not enough for a finite prediction.
  • latest_horizon_unavailable: The latest-horizon setting found no live prediction to take its horizon from.

What a refused row looks like

  • Kept: The subject keys, eligible set to false, eligibility_reason and the prepared input columns.
  • Missing: Every posterior output: level, growth, interval, precisions and weights.
  • Never substituted: Consensus or zero never stands in for a refused number.
  • Inputs are not a verdict: A retained input column can hold a value on a refused row; only eligible says whether to publish.

What raises instead

  • Malformed frame: A required column is absent, has the wrong type or repeats a subject key. PanelError is raised and no rows are returned.
  • Training window: With a known fitted_through, preparation raises PanelError for a reading date on or before it.

Further reading