Verification & results

A wipe is only as good as its verification. This page explains how the engine proves each erase actually happened, how outcomes are classified, what the Summary screen shows, and exactly what gets reported to the AVERASE cloud for certification.

Post-wipe verification

The engine verifies every technique, including firmware operations like sanitize and crypto erase — it never takes the drive's word for it.

Fingerprint markers, laid before the erase

Before the erase begins, the engine writes 32 random fingerprint markers at evenly-spaced 4096-byte sectors spanning the drive from first to last, and fsyncs them. These markers are the evidence baseline: after the erase, their fate proves whether the medium actually changed.

Reading back the real medium

After the technique finishes (firmware erases get a settle period first), verification runs:

Page-cache flush. BLKFLSBUF drops the kernel's cached view of the device, so every subsequent read comes from the physical medium — not from memory.
Representative-sampling sweep (for techniques whose expected result is all zeros), per NIST 800-88 §4.7.3: the drive is divided into up to 500 subsections; in each, two non-overlapping pseudorandom extents of at least 5% each are read (so at least 10% of the media is re-read in total), with the first and last LBA pinned into the sample. Unreadable sectors are counted as evidence, never skipped — a sector that cannot be read cannot be claimed zeroed.
Marker reconciliation. For zeros-expect techniques, every fingerprint sector must read all-zero. For crypto/block/format/revert techniques — where the post-erase content is unpredictable — the check is that every marker is gone, which simultaneously proves the erase changed the data and that the reads hit the real medium rather than a cache.
verification_hash. A SHA-256 digest is computed over every byte re-read during verification and recorded in the result — an integrity anchor for the sampled evidence.

The verification summary lands in the result verbatim, in one of two forms:

{zeroed}/{sampled} sampled sectors zeroed ({coverage}% of media re-read, 2 regions per subsection incl. first/last LBA), {fp}/{fp} fingerprint sectors zeroed
{fp}/{fp} fingerprint sectors overwritten (prior data non-recoverable)

The outcome model

Every job is classified along three independent axes.

Wipe status

`wipe_status`	Meaning
`pending`	Queued, not started
`running`	Erase or verification in progress
`completed`	The technique and verification ran to the end
`failed`	The technique failed, verification rejected the result, or no Purge technique existed
`cancelled`	The operator cancelled mid-wipe

Validation

`validation`	Meaning
`approved`	Verification passed — the erase is certifiable
`rejected`	Verification found surviving data — the erase cannot be trusted
`unverified`	Completed but held for secondary validation — not certifiable as-is

Disposition

`disposition`	Meaning
`sanitized`	Safe to release — data is non-recoverable
`destroy`	Route the drive to physical destruction
`review`	Hold for human review / secondary validation

How they combine

When a job finalizes, the axes are set together with a terminal message (verbatim):

Outcome	`wipe_status`	`validation`	`disposition`	Terminal message
Verification approved	`completed`	`approved`	`sanitized`	`Completed — sanitization approved`
Verification unverified	`completed`	`unverified`	`review`	`Completed but unverified — hold for secondary validation`
Verification rejected	`failed`	`rejected`	`destroy`	`Verification rejected — route to physical destruction`
Technique error / no Purge technique	`failed`	—	`destroy`	`Failed: {err} — route to physical destruction`
Operator cancelled	`cancelled`	—	—	`Cancelled by operator — drive left partially erased`
Aborted before writing (identity check, preflight)	`failed`	—	—	`Aborted before wipe — {err}`

Flash media caps Clear at review. A verified Clear on solid-state media (NVMe, or any non-rotational drive) is downgraded from approved to unverified with the note: NIST 800-88: Clear overwrite cannot reach over-provisioned cells on solid-state media — validation capped at REVIEW (use Purge to certify flash). Purge is the certifiable path for flash.

Certifiability: the AVERASE cloud issues a certificate only when wipe_status is completed and validation is approved (a blank validation counts as approved). An unverified/review result is persisted but flagged; rejected and failed results never certify.

The Summary screen

When all jobs finish, View summary opens the Summary screen (band title Summary). Each job shows:

Method — plus the auto-selected technique.
Result — the terminal status, colored.
Disposition — sanitized (green), DESTROY (red), review (amber), or —.

The footer reads:

Certificates are issued by AVERASE cloud — download them from your account.

The Summary screen deliberately shows no per-drive server status — certificates are rendered and signed only in the cloud (no signing key ships in the ISO), so the web app is the source of truth for certification. If nothing has been wiped yet, the screen shows Nothing to summarize yet.

The wipe result payload

After all jobs reach a terminal state, the engine sends one wipe result per drive to POST /api/wipe_result on the engine Worker. Job ids carry a per-drive suffix ({job_id}-0, -1, …) from the run's single check-in.

Properties

Name
job_id
Type
string
Description
The check-in's job id with the drive's index suffix (e.g. job_abc123-0). Unique per drive — the cloud keys one wipe result and one certificate on it.
Name
drive_serial
Type
string
Description
The drive's serial number, read from the hardware.
Name
drive_model
Type
string
Description
The drive's model string.
Name
drive_capacity_gb
Type
integer
Description
Capacity in decimal gigabytes (bytes ÷ 10⁹).
Name
wipe_method
Type
string
Description
The operator-chosen method label: NIST 800-88 R2 Clear or NIST 800-88 R2 Purge.
Name
passes_completed
Type
integer | null
Description
1 for overwrite-class techniques; null for firmware operations (crypto erase, block erase, format, PSID revert), where "passes" is not a meaningful measure.
Name
started_at
Type
timestamp
Description
UTC start of the job (ISO 8601).
Name
completed_at
Type
timestamp
Description
UTC end of the job (ISO 8601).
Name
verification_hash
Type
string
Description
SHA-256 over every byte re-read during verification.
Name
wipe_status
Type
string
Description
Terminal status: completed, failed, or cancelled.
Name
technique
Type
string
Description
The auto-selected technique label, e.g. NVMe Sanitize — crypto erase.
Name
validation
Type
string
Description
approved, rejected, or unverified.
Name
disposition
Type
string
Description
sanitized, destroy, or review.
Name
markings_removed
Type
boolean
Description
true exactly when the disposition is sanitized.
Name
tool_components
Type
string
Description
Engine and tool versions recorded at preflight, e.g. averase-engine 1.0.0; nvme version 2.4.
Name
verification_result
Type
string
Description
The verbatim verification summary — either the sampled-sectors form ({zeroed}/{sampled} sampled sectors zeroed ({coverage}% of media re-read, 2 regions per subsection incl. first/last LBA), {fp}/{fp} fingerprint sectors zeroed) or the marker form ({fp}/{fp} fingerprint sectors overwritten (prior data non-recoverable)).

Wipe result

{
  "job_id": "job_abc123-0",
  "drive_serial": "S6MZNF1WA04527",
  "drive_model": "PM9B1 NVMe Samsung 512GB",
  "drive_capacity_gb": 512,
  "wipe_method": "NIST 800-88 R2 Purge",
  "passes_completed": null,
  "started_at": "2026-06-21T11:30:05Z",
  "completed_at": "2026-06-21T11:47:12Z",
  "verification_hash": "9f2c…",
  "wipe_status": "completed",
  "technique": "NVMe Sanitize — crypto erase",
  "validation": "approved",
  "disposition": "sanitized",
  "markings_removed": true,
  "tool_components": "averase-engine 1.0.0; nvme version 2.4",
  "verification_result": "Pass — 32/32 fingerprint sectors overwritten (prior data non-recoverable)"
}

What happens next in the cloud

The engine Worker forwards each wipe result to the AVERASE cloud, awaited — the engine sees the outcome of persistence, not a fire-and-forget ack. In the cloud:

The result is persisted, keyed idempotently on job_id — a retried submission cannot create a duplicate record, and each drive keeps exactly one wipe result.
For a certifiable result (completed + approved), a certificate generation job renders two signed PDFs — the Certificate of Sanitization and the Erasure Report (Ed25519-signed, with an HMAC tamper token) — and stores them for download.
The Worker's acknowledgment includes a certificate_status, which the engine logs but does not display — the Summary screen directs the operator to the web app instead.

Browse results at /webapp/wipes, and see Certificates for the certificate's contents, signing, and the public verification endpoint.

Read about certificates