postforecast

Consensus-relative methods applied to forecasts produced elsewhere

This library does not forecast anything. Give it a forecast, a consensus and, when you have them, actuals: it anchors each value to when it was knowable, measures the forecast against consensus, combines the two, and states what it published and which parameters produced it.

Post means after the forecast, not after the fact. Every parameter is fitted on the training period alone, and no value is read before its known_at.

TipStart with a real model

Follow the terminology introduction, then learn to improve an existing forecast and measure whether post-processing helps. The real model walkthrough explains the calculations in detail. Load an ADC export and see how anchoring and the Bayesian posterior turn the same readings into explained estimates. These pages are grouped under Tutorials → Model methodology.

Find the right documentation

The site follows Diátaxis, with a route for each kind of task:

• Tutorials: Learn the package through executable notebooks, starting with the input panel and working toward a published estimate.
• How-to guides: Publish a feed, configure the complete Bayesian workflow, inspect refusals and retain an audit record.
• Reference: Look up API entry points, data contracts, mathematical definitions and the production-reference coverage audit.
• Explanation: Understand point-in-time rules, method assumptions and the design constraints learned from the original study.

Why it exists

A revenue forecast sold to investors is judged twice, and the two judgements pull against each other.

• Accuracy. How far is the number from what the company reports? A forecast of $1,300m beside a consensus of $1,000m looks absurd, and the user stops trusting the product.
• Information relative to consensus. When the number is above consensus, does the company tend to beat? A forecast that repeats consensus is perfectly credible and tells the customer nothing.

The customer’s question is never “what will revenue be?” — they already have consensus. It is “where is consensus wrong?” Every method here answers that question, and every one of them is auditable a year later.

What makes it different

The arithmetic is simple. The value is that a published number can be defended. Four properties, each mechanically enforced rather than documented:

• Pure. No file, no network, no process, no clock. import-linter forbids the modules, so a method that cannot read a clock cannot depend on when it ran.
• Point-in-time by construction. Values enter through the anchoring functions, which read strictly before a stated moment. A method sees only the anchored frame.
• Train and apply are different types. fit takes the training rows and returns a frozen object; apply takes any rows and cannot refit. A look-ahead has to be written deliberately, not reached by accident.
• Every result is attributable. A fitted method serialises to a plain dict: its parameters, their version, and what it was fitted through.

The two methods

	Anchored estimate	Bayesian posterior
Form	consensus, moved a fraction of the way toward the forecast	precision-weighted mean of prior, model and consensus
Space	ratios to consensus	growth, converted back to levels
Weights	one shipped set, versioned	per company, from each source’s own error history
Anchor	consensus, explicitly	none; consensus is one source of three
Interval	none	Student-t, heavy-tailed
Adapts as data arrives	no, the weights are frozen constants	yes, the precisions update every period

They answer different questions. For a published revenue number the Bayesian form is better founded: a per-company weight, an uncertainty band, and it degrades gracefully when a model’s record is too short. For a trading signal the fitted form has one decisive advantage — it is fitted on the quantity actually being predicted.

Both are reached through one protocol, so a caller swaps one for the other without knowing how either works.

Reading order

1. The panel — the one input format, and what it refuses.
2. Point-in-time — the read itself, and why fit and apply are different types.
3. Anchoring — the first method, end to end.
4. Bayesian posterior — the second, and how the two relate.

The tutorials are Jupyter notebooks with saved outputs, viewable directly on GitHub. just docs build executes them against the installed library before Quarto renders the same files. Edit the notebooks; just docs execute refreshes their saved outputs.

Provenance

Both methods are ports, not inventions. The anchored estimate and the Bayesian posterior come from the buy-side consensus study’s reference implementations, and the Bayesian one follows IndependentBayesianRegularizedPredictionSignal in the Exabel production DSL. Each reference ends in a self-check with real numbers, and those self-checks are golden tests in this repository, so the library and the published research cannot drift apart silently.