Show the source.
Keep the nuance.

Three evidence states.

AI contribution verified. We inspected a public development record that explicitly attributes an AI contribution, such as a code commit with an AI coauthor credit. This verifies that the record makes that attribution; it does not independently prove who typed each line, how much AI was used, or that AI built the original product.

Maker claimed. A project owner explicitly says AI coding tools were used in a README, official website, launch post or development log. We link the claim and do not turn it into an independently verified fact.

Unknown. We could not find enough attributable information. Open source, an AI feature, an agent instruction file, or a familiar interface does not establish AI-built provenance.

Original build versus later contributions.

We store original-build attribution separately from contribution evidence. A conventional application does not become a vibe-coded original merely because a later patch credits an AI assistant. If original AI-build evidence is missing, the app profile explicitly says unknown and a contribution alone cannot make a software guide eligible for indexing.

What counts as an alternative?

A relevant, documented workflow overlap, not a promise of complete replacement. Every listing records its scope and practical limitations. We distinguish local desktop use from self-hosting a service. Missing facts remain unknown.

Source hierarchy.

Official documentation, public repositories, maker statements and attributable development records come first. Community directories and social feeds provide leads. Their badges, pricing and metrics are never copied as verified facts.

The direct-replacement test.

Public listings need an available implementation for the same core job as the named incumbent, an explicit switching scope, practical steps and a sourced caveat. A different adjacent workflow, an integration that still requires the incumbent, or an aspirational clone is held out. Lack of an independent runtime test is disclosed; it is never rewritten as a tested or seamless switch.

Indexing quality gate.

A software landing page is eligible only when an editor approves it, its original-specific context is substantive, it includes at least three migration criteria, and it has a relevant approved alternative with explicit AI attribution, three sourced capabilities and clear limitations. Research gaps are noindex and excluded from the sitemap. Single-project pages say “one documented option,” not “best alternatives.”

Freshness and repository metrics.

Source-check dates describe an actual editorial source review. Automated repository checks record a separate metrics retrieval time. We fetch stars and repository activity through GitHub's API, cache responses and stop on rate limits. A metric refresh never silently renews the editorial source-check date.

Community content and moderation.

Maker submissions and comments are stored in a review queue. Approved community posts remain maker claims until the catalogue receives an evidence review. Votes are user interest signals, not evidence of reliability. One account can have one vote per app.

Corrections and commercial relationships.

Use the correction link on an app profile to submit better evidence. Future paid placements will be visibly labelled and time-limited. Payment does not change evidence status or comparison facts.