VNISH GLOBAL Academy

VNISH GLOBAL · Academy

Listed, Route-Verified, Installed and Site-Validated Are Different States

A catalog entry is discovery, not installation proof. Route-verified means a specific model, variant, control board, build and install path were checked together. Installed describes one device state; site-validated adds measured operation under stated site conditions. Skipping a state turns uncertainty into an unsafe claim.

Reviewed: Author: VNISH GLOBAL Academy editorial teamReview: Technical self-check

Working method

  1. Listed: the item exists in a current VNISH data source. It does not prove that a particular device matches it.
  2. Route-verified: the exact route passport has model, cooling class, board, current state, install method, filename, version, size, SHA-256 and a recovery path.
  3. Installed: readback from the target device confirms the expected build identity. This alone does not prove stable mining.
  4. Site-validated: the operator records cooling, wall power, pool-side work, errors and an observation window for that unit and site.

1.3.6 evidence

Current verified artifact example

Example only for Antminer S21 air-cooled / AML / NAND. It is not a route for Hydro, Immersion, XIL, CV or BB hardware.

Filename
vnish-s21-aml-nand-v1.3.6.tar.gz
Bytes
21,565,527
SHA-256
8679f6540f8b9f3cfe3f747d6d44399f8b277c7abaccc6efc99c3cdd52e15a2f

Release 1.3.6manifest.jsonSHA256SUMS.txtChoose an exact build

HOW TO INSTALL FIRMWARE

Work through a situation

Learning scenario - not a reported customer result.

Imagine a hypothetical support record containing a catalog entry, a downloaded archive and a matching SHA-256 value. This is useful evidence, but it answers a narrower question than 'May this miner be changed now?' The comparison shows that the archive matches the recorded reference bytes. It does not fill in an unknown control board, prove that the installation method fits the current firmware state or supply a missing recovery plan.

Work through the record one claim at a time. A catalog entry supports 'listed'. A complete, checked hardware and procedure record may support 'route-verified'.

After a change, a readback of the expected build supports 'installed'. Evidence of accepted work, cooling and operation under named site conditions is needed for the separate site-validation decision. If the record stops at the first stage, label it there instead of borrowing confidence from a later stage.

Preserve the source domain and retrieval time beside the file identity. An identical filename from somewhere else is not a reason to silently substitute the download or its support route.

Limits and stop conditions

  • SHA-256 proves byte equality with a published value; it does not by itself prove origin, compatibility, safety or recoverability.
  • If a required route-passport field is UNKNOWN, stop and resolve it rather than choosing by family name.
  • One validated unit is evidence for that unit and cohort, not every device in a fleet.

Reusable artifact

#FieldCheckedEvidence / note
1Exact model, submodel and cooling class□
2Control-board platform and identifier□
3Current firmware/security state□
4Target filename, version, size, SHA-256 and source□
5Install route, recovery route, checked_at and reviewer□

Copy this structure into a change record; never place passwords, keys or private access details in it.

Terms used in this guide

Listed
Present in a catalog or release record; not proof that one specific miner matches.
Route-verified
A checked combination of exact hardware, current state, target artifact, installation method and recovery path.
Provenance record
A record of where an artifact was obtained and which identity and retrieval details were retained.

Check your understanding

These questions check understanding. They do not approve an installation or certify a result.

  1. What does a matching SHA-256 comparison establish?

    Show answer

    Equality with the recorded reference hash, not universal origin, compatibility or recoverability.

  2. May an unknown required route field be treated as a likely match?

    Show answer

    No. Keep it unknown and resolve it before permitting the change.

  3. Does confirming the installed version establish site validation?

    Show answer

    No. Operation under the stated site conditions needs its own evidence.

Primary sources