Re-band five adoption records from verified package figures

[ccerv1]

Two spot checks found stars understating products whose primary distribution is a package or a container image rather than a starred repository. Sweeping every stars_fallback record for a package the project itself installs from, then verifying ownership by hand, found five where a measured monthly figure was available and simply never declared.

product	was	now	figure
firecrawl	3, stars	4, usage_volume	6,614,973/mo firecrawl-py
typesense	3, stars	4, usage_volume	1,180,052/mo typesense
lakefs	2, stars	3, usage_volume	536,650/mo lakefs
tensorlake-sandbox	1, stars	3, usage_volume	143,429/mo tensorlake
otari	1, stars	2, usage_volume	28,523/mo otari

Each now declares the package as an artifact, so the warehouse measures the same instrument the record claims instead of falling back to stars. All five were pre-existing records; none came from a recent batch.

Ownership was established by hand, per package

A repository-link check is not sufficient and is what hid these. Only firecrawl-py names the repository as its home_page. typesense establishes ownership through a Source project URL, lakefs through a Homepage URL pointing into treeverse/lakeFS, tensorlake through Homepage and Repository URLs, otari through mozilla-ai.github.io/otari. The same blind spot rejected tensorflow-serving-api earlier, whose owner is "Google Inc." and whose homepage is tensorflow.org/serving.

The sweep is a candidate generator, not a corrector

It produced two false positives that would have been severe:

• packaging at 2,191,710,133 monthly downloads attributed to bigcodebench
• openai at 417,881,229 attributed to simple-evals

Both because an install line names dependencies alongside the product, and in the second case because an owner-name match saw "openai" in both the org and the package. It also matched pnnx to ncnn — that one is genuinely Tencent's own conversion tool, but it is a sub-tool rather than the product. Nothing from the sweep is applied without a person confirming the package.

Two deliberate non-changes

pgvector is not re-banded. Its container image has 164,768,842 pulls, but that is cumulative since publication and the adoption scale is explicitly monthly. Treating a lifetime total as a monthly figure is the overstatement the guide strips numeric labels for.

A rate limit is not a finding. The first sweep run drew HTTP 429 from pypistats for four of the five, and the banding loop turned "no data" into "0 downloads, level 1" — a rate limit recorded as a measurement. The script now refuses to band a fetch that did not return 200, and retries with pacing. Worth stating because the failure was silent and would have shipped four wrong bands in the opposite direction.

Gates

All 14 offline CI steps pass.

[ccerv1]

Reverted and closed. The re-bands were wrong on role, and two of them reversed a judgment the corpus had already recorded.

The distinction I missed: this package belongs to the project is not downloads of this package measure adoption of the scored product. All five packages are clients or SDKs for a server, service or gateway — confirmed from their own PyPI summaries:

package	its own summary
typesense	"Python client for Typesense, an open source and typo tolerant search engine."
firecrawl-py	"Python SDK for the Firecrawl API"
lakefs	"lakeFS Python SDK Wrapper"
otari	"Python client for the otari gateway" — the package's own title is "Otari Python Client SDK"
tensorlake	"Tensorlake SDK for agent sandboxes"

Worse than a missed distinction: two of the notes I overwrote already said this.

• typesense: "The typesense package on PyPI is the Python client for a running server, so its downloads are not the product's. With no published deployment figure the stars scale applies, capped at 3."
• lakefs: "The lakefs package on PyPI is the Python SDK wrapper for the server's API rather than the server, so its downloads measure client use."

And firecrawl's note had reasoned the general case: "a paid API sells credits rather than reporting usage — so there is nothing here to band as usage volume."

So this is the resolution-ledger failure again, in a place that needed no ledger. The judgment was in the field I was replacing, and a scripted re-band did not read it. Declaring these artifacts would have made the warehouse more confidently wrong, because routing prefers a precisely measured but semantically weaker channel over stars.

Nothing here is worth keeping in the corpus. The 429 handling — a non-200 fetch must refuse to band, never record an absence as zero — lives in #426, where it belongs, along with artifact role as a first-class finding.