Methodology
This site makes one promise: every number traces back to a measurement, a source URL and a rule you can read. Below is how that works, including the parts that do not work well yet.
There is no AI in this product
No model is called anywhere in the running system — not remotely, not locally. That is a constraint we set ourselves, and it forces two useful properties. Identical input always produces identical output, so a number can be reproduced. And every claim can be traced to the rule that produced it, so a wrong claim is a rule you can fix rather than a mystery.
There is no sentiment analysis
We never ask whether an article is positive or negative. Word-counting sentiment is a blunt instrument, and on a subject where half the coverage is rewritten marketing it is worse than useless.
Instead we ask what kind of event an article describes — a release, an outage, a price change, a lawsuit — using explicit rule patterns. Whether an event type counts for or against a tool is written down in a versioned rules file, by a person, in advance. That is the difference between an opinion and a measurement. This layer is not live yet; it arrives with scoring.
How coverage is counted
An article counts for a tool when one of the tool’s registered names appears in its headline or summary. Names that are also ordinary English words carry extra rules: Perplexity is also the standard measure of model quality, Runway is also an airport and a startup metric, Claude is also a first name. Those names only match when supporting words are nearby, and never when a disqualifying phrase is.
Every match stores which rule produced it and the surrounding text, so a wrong match can be found and corrected instead of quietly distorting a count. The tool pages list which of a tool’s names are guarded this way.
“Coverage” on the tools page counts the last 30 days. The sources column counts only publishers independent of the vendor — a company blogging about itself cannot raise its own number.
How articles are grouped
Two articles are treated as the same story when they share at least 35% of their meaningful words, with a minimum of 3 shared words, within a five-day window. Articles from the same feed are never grouped: no publisher reports the same event twice, so overlap within one source is boilerplate rather than a story.
Announcement words are excluded from that comparison. That is not a guess — two unrelated posts, “Introducing OpenAI o1” and “Introducing the SQL Console”, scored a quarter similarity on the single shared word “introducing”.
The grouping is deliberately conservative. A missed grouping counts one event twice, which is visible and fixable. A wrong grouping makes an event disappear, and you never see that again.
Near-identical rewrites
Separately, we measure whether two articles are near-identical in wording, using a SimHash distance of at most 10 over headline and summary. That usually means the same press release rather than separate reporting. It is shown as a count, not as an accusation.
Where this is weak
Text similarity is a stopgap. Most feeds send only a headline, and independent reporting on the same event often shares almost no wording. We measured this: two articles about the same event can sit further apart in SimHash distance than two articles about nothing in common. That is why grouping does not use SimHash at all, and why the real fix is event extraction rather than better text matching.
What we store
Headline, at most 300 characters of the summary the publisher put in their own feed, the date and the link. Never a full article. Every headline links back to the publisher.
Sources
Vendor blogs, independent press and community sources are labelled separately everywhere, because a vendor is not an independent source about itself. Which feeds we read, when each last delivered, and which are switched off and why is public on the sources page — a source that quietly dies lowers the apparent attention around a tool, and you cannot check a number without knowing what fed it.
Scores
Six axes: independent coverage, shipping cadence, reliability, transparency, adoption and risk record. Each one normalises a measured quantity onto 0–100 on a saturating scale — twenty independent stories in a month is exceptional, forty is not twice as good.
Every score stores its formula version, its rules version and a hash of the inputs it used. Identical inputs and identical versions must produce an identical result, and an old score stays valid and explainable after the formula changes.
Missing data is not a zero
This is the rule that matters most. An axis we cannot measure is left out of the sum and its weight is redistributed across the axes we could measure — it is never counted as a bad score. Otherwise you measure your own blind spot and put a number on it.
What remains is coverage: how much of a profile’s weight actually rests on measurements. Below 60% we show the axes but no total at all. A single figure resting on half the picture invites exactly the reading this site exists to avoid.
Profiles
The same facts, weighted differently. A developer cares about shipping cadence, a privacy-conscious buyer about transparency and incidents, an enterprise about reliability. Every profile sets every weight explicitly — none inherits from another — and the choice lives in the URL, so a weighting you picked is a link you can share.
What counts against a tool
Only these event types, with the weights written down in advance: shutdowns, data breaches, security incidents, lawsuits, deprecations, regulatory action, terms changes and layoffs. A rumour counts half, because it is news but not an established fact. Outages deliberately do not appear in that list — they are already measured by the reliability axis, and counting them twice would penalise exactly the vendor who keeps an honest status page.