Skip to content

Methodology

How a listing gets here

Five steps stand between a public trace of software and a listing in this index. Each one below carries its written rule, a computed heartbeat, and — where we already publish one — a computed result. The text never claims a step is alive; the heartbeat does.

System state as of 12 Oct · 05:00 UTC · every figure computed, none written by hand

1 · Candidates arrive

Candidates enter from six families of public surfaces — package registries, app stores, code hosts, vendor sites, curated directories and public web mentions. A trace only becomes a candidate if it points at something publicly reachable. Candidates wait in a queue; position in that queue cannot be bought, and payment never speeds anything up.

Last new candidate seen: 12 Oct · 04:59 UTC

What this heartbeat can and cannot say: today a re-queued old candidate moves its existing row rather than creating a new one, so this date means “a new candidate arrived”. If that maintenance behaviour ever changes, this stamp could tick without real discovery — we state the assumption here rather than hide it.

2 · Most traces never become a record

Before anything is written down, a trace must look like a running project: a page that opens, software behind it, and a subject that is software rather than writing about software. Most candidates stop here.

Stopped before a record existed: 167,753

Counted over the decision-retention window, and bounded by it in the query rather than assumed of the prune job. The number of days is enforced by that job and printed here from its own heartbeat — 30 days.

  • Writing about software, not software59,470
  • Read, and not a product53,411
  • The page could not be opened22,776
  • Excluded by standing policy22,730
  • Nothing running behind it yet9,366

These counts do not add to the assessment figures in step 3 — this is the population that never reached assessment, kept separate on purpose.

3 · What passes gets assessed

A record is assessed on the kind of evidence behind it — a public project page, a store listing, a repository, independent mentions — never on who submitted it or where we found it. The exact evidence thresholds are deliberately not published — a number here would be a recipe for manufacturing exactly that number.

Assessed: 407,070 · listed: 375,134 · assessed, not listed: 31,936

  • A store page with no project behind it12,401
  • Removed from the catalog10,745
  • Identity could not be resolved6,331
  • Reason not recorded1,071
  • Outside the covered window (retired)1,054
  • Withheld under content policy123

The rows are counted in their own pass and can trail the line above by a few dozen records; they are the reasons, not a second count of the same number.

The same families, with the standing rules they enforce, live on Coverage rules — including how to contest a decision.

4 · What stands gets listed

“Listed” means: this project existed on public surfaces, the evidence held together under the rules above, and the record is now visible and countable. It does not mean we endorse the software, that it is safe, maintained, or good — those are claims we do not make.

Tracked in the index right now: 375,134

One quantity, one value: steps 3, 4 and 5 print the same figure — and it is the same figure the operations band at the foot of this page prints, adopted from there rather than counted again. Not several counts that agree; one value, rendered several times.

5 · Listed things keep being checked

A listing is not a one-time stamp. Listed records are re-checked in sweeps — a full pass over the catalog, with listings that have stopped answering re-checked in between; a project that stops answering loses its live status, and a host that repeatedly fails to answer is set aside for a period before we try again. When the next full pass is due is on Status.

Re-check coverage: 333,440 of 375,134 listings ever re-checked · last stamp: 12 Oct · 04:19 UTC

§ · The limits of our own records

First: since 13 Aug 2026, a listing admitted through a fetched page has that page written down when its record was made — its address, status, title and an excerpt of its text; listings admitted from registry and store feeds carry their dates instead, as do listings admitted before that date. A snapshot is kept for as long as its listing stays in the index and for 90 days otherwise. Last snapshot written: 12 Oct · 04:58 UTC.

Second: our own error rate. Every listing is held to a written 40-dimension listing standard (name, publisher, description, price, category, links, liveness); how well we meet it is measured on random samples — 24 dimensions by rule, on a fresh sample of 1,000 listings every week (last run 5 Oct 2026), and 11 dimensions by two independent models from different families, quarterly, checked against human-labelled listings; 7 dimensions are in both sets, so 28 of the 40 are checked today.

Measured against that standard: 19.0 % of a random sample of 200 listings met every one of the 28 checked dimensions (95 % interval 14.2 %–25.0 %) — an error rate of 81.0 % on the checked dimensions · audit of 3 Sep 2026 · next by 2 Dec 2026

§ · Methods and their versions

Some of what this index publishes is decided by a written method. Each one below carries its definition, its current version, and every change recorded against it, dated by the day the change reached the code. Answers from /api/apps name the versions they were computed with, in meta.methods — see Developers.

A change to the files that state a method’s rule has to add an entry to its changelog: a new version when what the method publishes changed, the same version with a note when it did not. The checks that run on main fail for as long as those files no longer match the newest entry.

edition

A monthly frozen copy of every record in the indexed catalog — identity, listing and visibility, liveness, category, pricing, license and the dated first-shipped and first-seen facts with their basis — as it stood when the edition was captured.

Version ed-v2 · valid from 2 Oct 2026

  • 2 Oct 2026 · ed-v1 — First edition method (3dba9b3d0): one row per record, category copied from a legacy category field.
  • 2 Oct 2026 · ed-v1 — The insert is chunked by Postgres bind variables (fdae04c33); the first production pass had sent 48,000 in one statement and was refused. Row content unchanged.
  • 2 Oct 2026 · ed-v1 — The pass refuses a named month or backup label and always writes the current month from the live catalog (58a156fd0). Row content unchanged.
  • 2 Oct 2026 · ed-v2 — category is the slug of the record's primary taxonomy node (df1f17e98). The legacy field ed-v1 copied was empty on all 368,117 records, so the 342,503 ed-v1 rows of 2026-10 carry no category; they stay beside that month's ed-v2 rows.
  • 3 Oct 2026 · ed-v2 — The pass gives the first-seen basis the backfill record's row, through the reader the site's list endpoints use, instead of only whether a row exists. Under first-seen-basis v2 a bare row reads unknown above the catalog's first row; on 2026-10-03 that was 8,718 records of the 2026-10 pool, 5,434 of them backfilled, which the 2026-11 edition would have frozen as unknown. The row's columns are unchanged; the 2026-10 edition was captured under first-seen-basis v1, where a row alone made a date backfilled.

supply-index

How common a price posture is inside a market compared with all listings the index counts — visible listings in its markets that carry a posture — as (n(M,P) / n(M)) / (n(P) / n(all)), so 1.00 means exactly as common; captured as a weekly edition.

Version v1 · valid from 13 Aug 2026

  • 13 Aug 2026 · v1 — Version introduced with the weekly editions (ca9b873a3), over the index as first published that day (7f9ddccf1).

correction-log

What a hand correction to a record must state — the field, its value before or after (at least one), a written reason and who made it — kept in a ledger that refuses edits and deletions.

Version corr-v1 · valid from 2 Oct 2026

  • 2 Oct 2026 · corr-v1 — Ledger introduced (a8b82cd23); every row is stamped corr-v1 by the column default.
  • 7 Oct 2026 · corr-v1 — recordCorrection can now write inside the caller's transaction, so a hand edit and its row commit or roll back together (markAlive used to commit the edit first and report a failed log). SAME version: a row still states the same things under the same append-only rules, and a reader cannot tell a row written this way from one written before it. What changed is which states are reachable, not what a row means.
  • 7 Oct 2026 · corr-v1 — The existing support-submission purge accepts an optional participation kind filter for operator cleanup. Its default behavior is unchanged. Correction rows, required facts and append-only rules are unchanged, so the published correction method remains corr-v1.

liveness

Which of three lifecycles a record is published with: Alive only when it is held alive and a liveness check has reached it, Confirmed gone only when its death rests on an evidence class allowed that label on measured precision, Unverified otherwise.

Version v2 · valid from 2 Oct 2026

  • 2 Oct 2026 · v1 — First versioned definition, at 6c682e7bb. Earlier changes to these rules were not versioned.
  • 2 Oct 2026 · v2 — A death holding several kinds of evidence takes the class of the strongest MEASURED one first (store listing, canonical package, site root), so a linked repo's deletion or a lapsed domain recorded after a root 404 no longer turns its Confirmed gone into Unverified (0 rows that day). Added beside it for the alive gate, which since then confirms and holds a death only on these classes: SETTLED_DEATH_CLASSES, settlesDeath, and the rule that a 404 speaks for a record only from its own listing or site root.

first-seen-basis

Whether a record's first-seen date is something we observed, a date a backfill wrote, or unknown — decided by what the backfill's own record shows it wrote, and by dates earlier than the catalog's first row.

Version v2 · valid from 3 Oct 2026

  • 13 Sep 2026 · v1 — First versioned definition, at 862baab30. Earlier changes were not versioned.
  • 2 Oct 2026 · v1 — A batch reader for a page of records (96a1453cc), built on the same resolver with the same three answers. Rule unchanged.
  • 3 Oct 2026 · v2 — A backfill record counts only for what it shows, not for existing. Rows of the scripts that moved dates (K, KB, U, R2) make a date backfilled while the date they wrote is still the record's; rows the 2026-10-02 rescue copied moved nothing, so they read observed where the forward policy could not have written the date and unknown where it could. A record rewritten since, a cohort the resolver does not name, and a caller that reports only that a record exists read unknown above the catalog's first row — the monthly edition's reader passed nothing more that day. On the visible catalog: 3,222 records backfilled → observed, 62 backfilled → unknown, 174,227 still backfilled.
  • 3 Oct 2026 · v2 — Notes in the definition file corrected — a discovery time is the source's own clock for some adapters, and the age test is the looser one only while discovery is not later than creation. What the method decides is unchanged.
  • 3 Oct 2026 · v2 — The page reader is now also the monthly edition's, so both hand the resolver the same row; notes in the definition files say so. What the method decides is unchanged.

Verify this page yourself

Every figure above is computed, never written by hand, and it comes from the same sources as Coverage rules, Status and Press numbers — open them side by side and compare. The catalog size is the live one: once the page has loaded it is the same value the band at the foot of this page holds, and a reload can move it because the index moves. Decisions can be contested through the path on Coverage rules. If a listing about your own project is wrong or you want it removed, use Report an Issue with the listing's address; what a request can change, and how a project's owner has it taken down, is set out on Coverage rules.

Each month the index freezes what it recorded for every tracked record into an edition that is never rewritten.

Corrections made to a record by hand are listed on Corrections.

The words above are used precisely and are not interchangeable. A candidate and a record are the two stages steps 1 and 2 describe; listed is narrower than either, and it is the same population the Glossary calls projects tracked, so the two words name one number, not two. Where each source family comes from is on Data sources.