Methodology
The VerifyCompute Standard
An open, versioned methodology for verifying AI compute hardware.
Section 1
Why a standard is needed
The ITAD industry has R2v3 and NAID AAA for data destruction. No equivalent standard exists for verifying the condition, authenticity, or custody of AI compute hardware.
Buyers, sellers, auditors, and underwriters currently work from seller claims. We are publishing our methodology openly so findings can be reviewed, challenged, and repeated by others.
Verification, provenance, and condition for AI hardware.
Pillar 1
Verification
Is this unit what the seller says it is?
Serial and component-level confirmation that the silicon inside the chassis matches the paperwork outside it. Covers GPUs, memory, storage, and benchmark integrity.
Pillar 2
Provenance
Where has this unit been, and who has held it?
The ownership and custody trail from original purchase forward. Invoices, receipts, transfer records, service events, decommissioning documentation, and export status.
Pillar 3
Condition
What state is this unit actually in?
Evidence-based grading covering thermal history, error counts, utilization hours, throttling events, and memory health.
Section 3
Verification scope
Component authentication
GPU, memory, and storage serials matched against recorded inventory; substitution and downgrade detection; firmware identification.
Telemetry integrity
Collector signature validation, internal consistency checks, and flagging of results that cannot be validated.
Physical inspection
Available as an add-on where remote collection cannot establish authenticity.
Section 4
Provenance scope
- Ownership chain from original purchase
- Purchase invoices and receipts
- Transfer records
- Service and RMA events
- Decommissioning documentation
- Export control status
- Gaps in custody explicitly identified rather than assumed clean
Section 5
Condition grading scale
Every finding is reported at one of four confidence levels.
Complete telemetry, full component match, unbroken custody chain, no unexplained gaps.
Substantially complete evidence with identified, documented gaps that do not undermine the core finding.
Material evidence gaps. Findings are reported with explicit limits on what can be concluded.
Evidence could not be validated. Reported as unverified rather than accepted.
Individual checks are reported as signals — a consistent signal, a signal needing attention, or a risk indicator. A signal is an observation about one piece of evidence. Only the four confidence levels above are reported as an outcome.
Section 5b
Readiness scale
A separate, pre-verification scale describing how complete a submitted evidence package is.
Ready for Verification
The expected fields and documents are present. The package can enter an evidence review as submitted.
Nearly Ready
Substantially complete. One or two items are outstanding and are named in the review.
Additional Evidence Needed
Several expected items are missing. A review would carry material limits until they are supplied.
Insufficient Evidence
Too little information was supplied to assess readiness beyond the fields provided.
Readiness is a separate scale from the condition grading scale above. Readiness describes the completeness of a submitted evidence package before any review. It is never a finding about the hardware and is never reported as a verification outcome.
Section 6
What this standard excludes
- Valuation, appraisal, and residual value estimates
- Price guidance or resale forecasts
- Generational performance comparisons or economic fitness for a given workload. A VerifyCompute grade describes condition and authenticity. Whether a unit suits your workload is a separate question.
- Manufacturer warranty claims
- Guarantees of future performance or useful life
Section 7
Versioning
Version 0.1 — September 2026
This methodology is versioned. Every report records the methodology version used to produce it, so a finding can always be read against the procedure that produced it.
Changes to the methodology are published with a changelog.
Section 8
Feedback
We invite operators, ITAD providers, auditors, and underwriters to comment on this methodology, challenge its assumptions, and tell us where it falls short.