Source hierarchy
Release versions, hashes, platform support, and product behavior should come from current publisher release notes or documentation. Repository history and direct package inspection may provide supporting evidence. Search snippets, forum posts, and reseller pages are not treated as authoritative release proof.
Compatibility claims
A model name alone is not enough. Compatibility guidance should identify the miner family, control-board variation, firmware state, requested action, and any documented limitation. Unknown combinations are marked unknown rather than inferred.
Comparisons
Comparison pages evaluate tasks, operating boundaries, deployment methods, and documented features. They do not use invented scores, fake benchmarks, paid rankings, or unverified market-share claims. Product names are not endorsements.
Downloads and screenshots
Hosted files are described with visible version, size, date, and checksum information where available. Illustrations and historical screenshots are labelled so they are not mistaken for a current interface or a security audit.
Updates and corrections
Review dates indicate when a page was checked. Material changes to upstream releases, compatibility, or safety guidance should trigger a new review. Corrections should update the affected fact and its dependent pages instead of silently preserving a known error.