How often the band rates a stock, and what we have not measured
Every stock page with enough filing history shows a fair value band and a positional label. This page publishes the latest stored run of the audit that checks which tickers get a band and why the rest do not. The audit is not rerun when you load this page: it is printed from the record of the run on 2026-07-22. It measures coverage. It does not measure whether the band is right, and the section below says why that has not been measured yet.
One run on 47 judgeable tickers, a small sample: read the share as a description of that run, not as a rate for every company.
Why the 5 did not get a band
- HCA, HLX, HON, O: no stored closing price.
- BK: the ticker lookup found no SEC filer.
Why 105 were not judged at all
The first reading of this run said 110 of 152 tickers had no rating. That was the audit, not the band: the run walked 181 tickers, and building each one’s multiple history costs one call to the price-history feed against an hourly allowance; the allowance ran out mid-run, so these tickers had no history to judge, which says nothing about the band. Those 105 are left out of the share above rather than counted as failures. The fix the run led to was a scheduled job that builds each ticker’s history ahead of time and stops when the allowance runs out, so a stock’s rating no longer depends on whether someone visited its page first.
How the audit works
- For each ticker the audit looks up the SEC filer, reads the stored close, builds the multiple history and runs the same band function the stock page runs (lib/fair-value-band-data loadFairValueBand).
- A ticker counts as rated when the band returns a label; otherwise the audit records why: no filer, no band, or a band with too few estimators to label, with the history coverage behind it.
- It runs only on request behind the cron secret, because each ticker costs SEC and price-history calls; nothing it finds is written back to any page.
Not measured: whether the band is calibrated: how often later closes landed inside it, by label
A band is worth trusting to the degree that later prices behave as its width says they should. We have not measured that, so this page prints no calibration figure. The reason: the label history is stored (each ticker’s label and the day it changed, since FI-005), but the band’s edges on that day are not, and a later close can only be scored against the band that stood when the label was set; rebuilding past bands from today’s filings would score the band with hindsight. What it needs: the band’s low and high stored beside each label snapshot, then a dated run that scores later closes against them, with the sample and its floor printed.
The labels on the stock pages are positional: they say where today’s price sits against the band, not where it will go. Nothing on this page grades them as predictions, because they are not made as predictions.
Where this result is recorded
The run is written down in decision D-267 (collab/DECISIONS.md) and decision D-268 (the fix it led to) (collab/DECISIONS.md) in the project’s repository, and the figures above are copied from there; a new run replaces them, a hand edit never does. The audit itself is the gated route /api/bandaudit.
Every validation test we run, including the ones that found nothing, is listed in the file drawer. The parser that confirms earnings dates has its own stored audit, and the earnings date labels have a walk-forward backtest. Back to methodology.