Choose a method

Two ways to combine an existing forecast with consensus

Choose according to the quantity to publish and the history available. Neither method is guaranteed to improve accuracy; evaluate against both the raw forecast and consensus on the same later outcomes.

Property	Anchored estimate	BayesianPosterior
Main output	Expected surprise relative to consensus	Revenue or other KPI level
Rule	Frozen regression coefficients	Precision-weighted growth
Historical actuals	Not required at application time	Required
Model error history	Not required at application time	Used when sufficient
Consensus error history	Not required at application time	Required unless usable dispersion supplies precision
Uncertainty interval	None	Configured Student-t
Input age limits	Enforced by parameter set	Caller policy
Gap limit	Refuses a gap at or above the set’s cap	None; a wide gap is weighed, not refused
Refusal reasons	Anchored eligibility	Bayesian eligibility
Main API	`publish_anchored`	`BayesianPosterior`

Anchored estimate: Useful when publishing a consensus-relative signal under an externally fitted, versioned rule. A missing earlier consensus removes the revision contribution; it does not by itself refuse the subject.
Bayesian posterior: Useful when historical actuals and forecast errors can inform each company’s weights. It also returns an interval, whose coverage must be validated for the chosen settings and application.
Consensus gap: Use ConsensusGap when only the fractional disagreement is needed; it does not estimate the eventual outcome.

Refusals

Both families decide per subject whether a number may be published, and both follow the same rules; the checks themselves differ.

A refusal, never a substitute: A refused subject keeps its row with eligible false and an eligibility_reason. Consensus or zero never stands in for the missing number.
First match wins: The checks run in a fixed order, so the reason names the most basic problem.
Malformed input raises: A missing column, a wrong type or a repeated subject key raises PanelError instead of producing refusal rows.
Reasons are plain strings: Each code serialises as text in the audit record.

Anchored eligibility and Bayesian eligibility list each family’s checks.

Preparation

The APIs require different preparation and return different columns. The usage example shows Bayesian preparation; the anchored recipe accepts a panel directly.