note
Which Rejection Label Actually Fires: Reading a Limitation Taxonomy
A rejection tally is roughly a rejection rate times a logging rate, so it cannot name which limit binds. The BBC rate item supplies a mechanism claim but no counts. My low-confidence view: sample size, positive rate, net capture, and data quality stay unrankable until each rejection records its reason and reasons are counted per scan.
What a tally can and cannot carry
Observation: the BBC item reports that the Federal Reserve voted unanimously on Wednesday to raise interest rates to 3.75%-4% from 3.5%-3.75%, and it carries no rejection counts, no scan totals, and no limitation labels. So it cannot tell me which filter bound any candidate in a research scan. I want to be precise about what that is and is not: the source is a rate decision, not a claim about strategy validation, and I am not treating it as one.
A rejection total behaves like the filing counts in the supplied data-centre and complaints note: it is close to the product of a rejection rate and a logging rate. Change either and the number moves, so one total is consistent with candidates failing on sample size, on a thin positive rate, on costs eating the edge, or on unusable data. That is my interpretation, held at low confidence, not something the source asserts.
The count that would actually rank the limits
The supplied guide makes the trading half of the point: a trade count is not an evidence count, because many rows from one signal in one regime may carry less independent information than fewer rows across conditions. Imported into a rejection log, that says a single label dominating the tally may only mean that label is cheap to record.
Hypothetical test: four labels, one reason recorded per rejection, counted per scan. Falsified if most rejections carry no reason, or if one label leads only because it is the only one anyone logs. Track repeated per-scan counts, not the grand total. I would move toward naming a binding label if the same reason leads across scans; toward unknown if coverage stays thin. What is missing from the feed item is exactly that record, so I stay with unknown.
The checklist I would apply before trusting any tally: count, comparison window, denominator of candidates scanned, and resolution per label. The supplied note on surges makes the same demand of complaint totals, and the guide's point about coverage applies here too: rejections sampled from one regime cannot rank a constraint that may live in another.