Skip to content

Listing criteria

Coverage Rules

What enters the global software index, what does not, and how coverage decisions are made. Inclusion follows public evidence, not payment.

Assessed231,489
Listed214,707
Assessed, not listed16,782

Why the rest were not listed

Every assessed listing that is not in the catalog, grouped by what stopped it. These add up to the 16,782 above.

  1. Removed from the catalog10,289

    Withdrawn after listing — by request, or because the record turned out not to hold up.

  2. Reason not recorded4,299

    Kept out before the reason was written down. These are the ones we cannot explain, and the count is here rather than folded into the others.

  3. A store page with no project behind it1,446

    The listing exists on a store or registry but carries no description, no working surface, or nothing that identifies a project.

  4. Identity could not be resolved652

    Ambiguous, a staging or mirror URL, or a surface that turned out to be a service rather than a project.

  5. Withheld under content policy54

    Adult or otherwise restricted material. Assessed, recorded, not published.

  6. Outside the covered window33

    Shipped before the period this catalog covers.

Turned away before any of that

Most candidates never become a listing to assess at all. Over the last 30 days 182,891 candidate pages were stopped earlier, for these reasons. Separate from the figures above, which count listings that were assessed; the two do not add up and are not meant to. The window is 30 days because that is how long these decisions are kept.

  1. Writing about software, not software78,693

    News stories, roundups, listing directories, company about-pages and link hubs. They describe products; this catalog tracks the products themselves.

  2. The page could not be opened43,509

    Bot protection refused the request, or the address did not answer. Nothing about a page that cannot be read is verifiable, so it is turned away rather than guessed at.

  3. Read, and not a product26,014

    The page opened and was legible, and what it turned out to describe was not software anyone could go and use.

  4. Nothing running behind it yet17,916

    A waiting list, a placeholder store entry, or a domain with no working product surface on it.

  5. Excluded by standing policy16,638

    Hosts and domains that are out by rule, plus material withheld under the content policy.

  6. Reason not recorded121

    Stopped before the reason was written down. Small, and counted here rather than folded into one of the families above.

Qualifies for listing

A project generally qualifies when it has a stable public identity, a clear software surface, and enough public evidence for PulseGate to anchor and monitor it consistently.

  • Public project URL
  • Recognizable software identity or official store listing
  • Enough corroborating evidence to avoid duplicate or low-trust inclusion

Does not qualify

Not every discovered URL should become a listing. PulseGate avoids listing thin, ambiguous pages, and pages that are not a project.

  • Single marketing pages with no evidence of a project behind them
  • Dead, suppressed, or clearly abandoned surfaces
  • Non-software pages, generic company sites, mirrors, and clones

Public-facing requirement

PulseGate only lists projects that can be verified from public-facing surfaces. Private dashboards, closed betas without public identity, and software nobody outside the company can reach are out of scope.

Duplicate and canonical handling

Discovered URLs are resolved toward one canonical project whenever possible. Multiple URLs, stores, or mirrors may map to a single listing when the public identity is clearly the same.

Directional coverage caveats

Coverage is designed to be useful, not exhaustive. Entire categories or geographies can have less complete coverage than others, especially where public structured data is scarce.

How to report a mismatch

If a listing looks miscategorized, duplicated, stale, or clearly outside coverage rules, use Report an Issue and include the affected URL or slug together with any public evidence that helps verify the correction.

Contesting a decision

Every listing decision here follows from public evidence, so new public evidence is what changes one. Send the URL or slug and what the record should say, with something we can check — a store listing, a repository, a changelog, the project's own page.

Reports reach the operator directly as mail. There is no ticket number, no queue position and no promised turnaround; the honest version is that a person reads it and either the record changes or it does not. A corrected record is re-assessed against these same rules on its next pass, so a change holds without needing to be re-argued.

  • What can change: category, canonical identity, the name a listing carries, whether it is listed at all
  • Delisting your own project: send the request from a surface you control and it comes off
  • What changes nothing: paying, asking often, or who is asking