Skip to content

Project · trust model

Verification

What the badge on an entry is claiming, and what it is not.

process

The four states

  • Verified — a maintainer read the entry against the tool's own documentation and confirmed the commands, install paths and platform claims for the recorded version.
  • Community — contributed and structurally valid (it type-checks, links resolve, no placeholder text), but not independently re-checked.
  • Needs review — known to possibly lag upstream. Treat every flag on the page as unconfirmed.
  • Outdated / Deprecated — kept for reference; not the recommended path.

What verification is not

It is not an endorsement of the tool, an audit of its source code, or a guarantee that a command is safe in your environment. It is a statement about the accuracy of this documentation at the recorded revision.

Verification never extends to results. Whether a command produces what you expect depends on version, privileges, target configuration and your position on the network.

Re-verification triggers

  • A contributor reports a mismatch with current upstream behaviour.
  • A documented command's syntax moved between major versions.
  • An install method disappears from a distribution's repository.
  • A tool changes licence model or stops being maintained.

Dates

Entries carry a last-revised date for the dataset (2026-01-19 is the current revision). There are no per-entry “verified on” dates, because that data would be invented. When precision matters, the upstream changelog is the reference — every tool page links to it.