Methodology
How the dataset behind this site is gathered, verified, and kept current. The short version: a primary source on every claim, licenses read from the upstream LICENSE file, a weekly update cadence with dated verification on every record, and every change auditable in a public git history.
Last reviewed · see also inclusion criteria and the impartiality policy
Source-backed or not published
Every factual claim in the dataset carries a primary-source URL — official documentation, the canonical repository, a vendor release note, or an official regulatory text. If a claim cannot be traced to a verifiable source, it is left out rather than guessed. Automated validators reject records with missing provenance before anything is published.
- Governance claims (data residency, audit logging, SOC 2, ISO 27001, ISO 42001, EU AI Act tier, license risk) require a source URL whenever a fact is asserted; an honest “unknown” with a stated reason is preferred over an unsourced “yes”.
- Update-feed entries always carry the source that reported the change.
- Secondary summaries never substitute for primary sources.
License verification
License accuracy is treated as a release-blocking invariant, not a metadata detail. Labels are read from the upstream LICENSE file of the actual repository, not from marketing pages or package registries.
- Any non-OSI-approved clause — Commons Clause, BSL/BUSL, SSPL, Elastic License, “source-available” terms — gets a plain-language warning on the record.
- License corrections never happen silently: a discrepancy opens a public data-correction issue with the evidence, and the field changes only after verification.
- Mislabelling source-available code as MIT is treated as a release blocker.
Freshness and the weekly update cadence
The dataset is refreshed on a weekly cadence: a scan for source-backed changes (releases, license changes, deprecations, certifications, renames, acquisitions) feeds the updates log, and dataset snapshots are diffed so routine drift is auto-detected rather than manually noticed.
Every tool record carries a dated “verified” stamp from its last governance review. A record whose review is older than 60 days is visibly flagged as stale on its page — staleness is disclosed, never hidden.
Canonical naming
Products are rendered under their current canonical name; prior names are preserved as aliases so external links and searches keep resolving after vendor rebrands. Renames are recorded as dated events in the change feed.
Review process and auditability
Every change — data, copy, or code — ships through a reviewed pull request in the public repository, so the full history of every claim is auditable in git. Automated gates validate schema conformance, provenance, license flags, and generated artifacts before anything merges.
What will be added to this page
When the maturity radar (editorial adopt/trial/assess/hold verdicts) and the reproducible readiness score ship, their criteria and formulas will be published here in full before either appears on a tool page. The verdict will be editorial, dated, and evidence-backed; the score will be mechanical, versioned, and reproducible from published rules — and the two will stay clearly distinguished.
Check the work
The dataset, the schema that governs it, the validators that enforce these rules, and the full change history are public in the repository. If a claim looks wrong, the correction path explains how to challenge it with sources.