RankquantRQ

Why we never change our published constants after the fact (and publish them on day one)

·

Correction, 6 August 2026. An earlier version of this article described Rankquant as assigning per-source credibility weights, and printed a table of them. That was wrong. No published Rankquant score has ever applied a source weight or any other per-source multiplier: the pipeline computes one unweighted mean of per-reviewer z-scores in which every qualifying reviewer counts equally. The weight tables have been withdrawn site-wide and the withdrawal is logged at /changelog. The article has been rewritten around the constants that do exist.

Goodhart's Law and Campbell's Law

The British economist Charles Goodhart formulated the rule that bears his name in 1975, in the context of UK monetary policy: any observed statistical regularity will tend to collapse once pressure is placed on it for control purposes. Donald Campbell, working independently in social-policy evaluation, formulated a stronger version: the more any quantitative social indicator is used for social decision-making, the more subject it will be to corruption pressures and the more apt it will be to distort and corrupt the social processes it is intended to monitor.

Achievement tests may well be valuable indicators of general school achievement under conditions of normal teaching aimed at general competence. But when test scores become the goal of the teaching process, they both lose their value as indicators of educational status and distort the educational process in undesirable ways.

Donald T. Campbell, "Assessing the impact of planned social change," 1976

What this looks like in review aggregation

In an aggregator that weights its sources, the weight table is the highest-leverage knob on the board: raise one publication's weight and everything that publication likes moves up. Rankquant does not have that knob. Reviewers are normalized onto their own z-scale and then averaged with no weights at all — no source, platform or publication is worth more than any other, and neither is any individual reviewer. Admission to the pool is the only distinction the pipeline makes, and once admitted, everyone counts once.

That removes one class of manipulation and leaves another. The pipeline still depends on constants, and a constant is a number somebody chose:

Each is a place where a number could be moved to move rankings. K is the clearest case. Because per-reviewer normalization puts the corpus average at exactly zero on the z-scale, multiplying a mean by n/(n + 53) pulls thin-sample items toward the middle: an item with three calibrated reviewers keeps about 5% of its measured distance from average. Set K to 5 instead and the same item keeps 38%. An operator who wanted to elevate boutique items carried by a handful of enthusiastic reviewers could do it that way without changing a single line of the aggregation code. There would be no statistical evidence of it on any individual item's page — the arithmetic is the same; only the constant moved.

Which is why the inventory matters. Wine scores come from the Vivino reviewer pool, films from IMDb blended with Rotten Tomatoes where it exists, books from Goodreads and Amazon, hotels from six booking and travel platforms, cruises from Cruise Critic, products from Amazon customer reviews. No professional critic publication is ingested. There is no credibility ladder anywhere in that list and no plan to add one: a source's contribution is however many qualifying reviewers it brings, each counted once. The constants are the entire tunable surface — which is what the rest of this article is about.

The defence is pre-commitment

Pre-registration — the practice of publishing your analysis plan beforeseeing the data — is the standard defence against this kind of post-hoc manipulation in clinical trials and increasingly in academic social science. The replication-crisis literature documented how flexibility in analytical choices (which covariates to include, which subgroups to analyse, which outliers to drop) lets researchers find "significant" effects in noise. The fix is to commit in writing, in advance, to what you will do.

Rankquant's constants are pre-registered in the same sense. Each one is written out at /methodology inside the step that uses it — the admission rules in the normalization step, K = 53 under the AI-adjusted percentile, z = 1.645 under the published confidence floor, the ±20% band under cohorts — and the specification is complete, because there is no weight table left off it. The changelog at /changelog records every methodology change with a date, a numerical diff, and a written rationale, including the August 2026 corrections that withdrew the source-weight tables. Every detail page records the methodology version it was scored under, so that if we change a constant in the future, anyone can read a score against the specification that produced it.

The rules we have committed to

The four structural defences against post-hoc tuning of the constants.
Publish on day oneEvery constant the pipeline depends on is written out at /methodology with its value and its rationale: K = 53, z = 1.645, the n_u ≥ 2 and σ_u > 0 admission rules, the ±20% cohort price band. There is no off-page constant — and no weight table of any kind, for any source or any reviewer.
Version-bump on changeAny change to any published constant increments the methodology version. The new version, the numerical diff, and the rationale appear in /changelog with a publication date.
Historical versions stay queryableEvery detail page carries the methodology version its score was computed under, in the methodologyVersion field of its Product JSON-LD. Older methodology versions stay published on the changelog page, so a historical score can be read against the specification that produced it.
No private constantsThere is no internal value different from the published one. Every detail page prints its own intermediates — the mean reviewer z-score, the calibrated-reviewer count it was taken over, and where it applies the 90% confidence floor — so a divergence between the published constants and the numbers we ship would be visible by hand, on any single page.
The four structural defences against post-hoc tuning of the constants.

The hard cases — when a constant legitimately needs to change

Pre-commitment doesn't mean constants can never change. It means changes are public events with stated reasons. There are three cases where we expect to bump one over time:

The bar for changing a constant is: can we publish a paragraph in the changelog explaining why?If yes, we can change it. If no — if the only honest answer is "we wanted a different ranking" — we can't.

Why this matters more than it might seem

Most review aggregators don't publish their weighting at all. Yelp's ranking algorithm is a black box. Amazon's "helpful" review promotion is opaque. Google Reviews don't expose any weighting. The few aggregators that do publish weights — Metacritic publishes critic weights; Rotten Tomatoes weights publication clout — reserve the right to retune those weights without public notice.

The result is that for any of those services, you can't verify that a product's score wasn't engineered. You have to trust the editorial team. Trust is fine when it's well-founded; it scales poorly when it's the only defence. We have no weighting to publish because we apply none; what we publish instead is every constant that does touch a score. The structural alternative — published constants, version-bumped publicly, historical versions queryable — gives you a verification surface that doesn't depend on trusting us.

Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.

Goodhart, "Problems of monetary management," 1975, paraphrased

The published-constants layer

The constants themselves are in the open, on /methodology, inside the prose of the step that uses each one. They are not numbers we hold privately and apply behind the scenes: every value is on a public page that anyone can read, archive, or diff against the Wayback Machine. If we ever change a constant without a corresponding changelog entry, the archived copies of that page will show it — and would be cited against us by anyone watching.

That's the strongest version of the defence. Editorial pre-commitment plus publicly published constants plus a versioned changelog forms a three-way verification surface that even a determined operator would have a hard time spoofing without leaving evidence. It is a smaller surface than this article used to claim, in the useful direction: a weight table would be one more set of numbers you had to take on trust, and there isn't one.

Frequently asked questions

How do I check what methodology version a score was computed under?+
Every detail page carries the methodology version in the methodologyVersion field of its Product JSON-LD, alongside the score-schema id of the vertical it belongs to. Every version, and every correction to one, is listed at /changelog/ with its date, so a published score can be read against the specification that produced it.
Couldn't Rankquant's editorial team just change a constant and pretend it was always that way?+
In principle, yes — that's why the verification surface is structural, not editorial. The changelog is publicly hosted, every constant is published on /methodology/ where third-party archives capture it, and any third party (including AI engines and journalists) can hash the methodology page over time and detect undocumented changes. We expect this to actually be done; the more verification, the better. The August 2026 corrections that withdrew the source-weight tables are on the changelog for the same reason.
Does Rankquant weight some sources or reviewers more heavily than others?+
No. Every reviewer is normalized onto their own z-scale first, and from there every qualifying reviewer counts exactly the same. There is no credibility weighting, no source weighting, no per-source multiplier and no weight table anywhere in the pipeline — an earlier version of this article said otherwise and was wrong. Admission, not weight, is the only distinction: a reviewer needs n_u ≥ 2 ratings to have a personal distribution at all, and a reviewer whose ratings are all identical (σ_u = 0) enters, where they enter, on a dispersion imputed from their source. Once admitted, they count once, like everyone else.
Which constants actually move a published percentile?+
Different ones move different figures, and all three published percentiles come from the same unweighted mean reviewer z-score. The global percentile is the empirical-CDF rank of that mean itself, so no constant enters it except the admission rules that decide whose ratings are in the mean. The in-cohort percentile is the same value re-ranked among close peers, so it additionally depends on the cohort definition — for products, the same category within ±20% of list price. The AI-adjusted percentile is the same value discounted for how much confidence the sample supports, mean_z · n/(n + 53), so it is the one figure K = 53 moves. The 90% (z = 1.645) confidence floor is published on each item beside its score as a diagnostic, not as the headline ranking key.
How does this interact with affiliate revenue?+
It doesn't, and there is currently no affiliate revenue to interact with — no affiliate program is active on this site. The outbound link for each category is fixed and built from the record's own identifiers, described in /methodology#affiliate. No published constant enters into it, and a retailer cannot improve a product's score by paying us: there is no weight to buy and no per-source multiplier to lean on.

Series: ← The small-sample illusion · Hub · Coming next: Survivorship bias — why we publish the full database, not just the winners