Hardware audit & tests
Before a machine is wiped, the engine documents it: a full hardware fingerprint collected automatically at boot, plus nine functional tests the operator runs to grade what actually works. Both flow into the machine's asset record in your account.
The device fingerprint
The Overview screen (band title Device fingerprint) is a read-only audit of everything the engine can discover about the machine — DMI/SMBIOS data, CPU and memory topology, storage with SMART health, EDID display data, batteries, and peripherals. Collection starts at boot and runs in the background; while it works the page shows Building fingerprint… and Collecting hardware…, and if collection fails you'll see Collection failed: {msg}. A machine with no discoverable disks shows No storage devices detected.
Data is presented as spec rows — muted label on the left, value on the right — grouped into sections. The band's Refresh button re-collects, and the Advanced toggle expands each section with deeper detail. Fields the hardware doesn't expose simply don't render; the engine degrades gracefully rather than guessing.
Default vs Advanced sections
| Section | Default rows | Advanced adds |
|---|---|---|
| System | Manufacturer, Model, Serial number, Chassis | Version, Family, Chassis serial, UUID, TPM, Firmware, Secure Boot |
| Motherboard / BIOS | Board vendor, model, serial | BIOS vendor, version, date; audio device rows |
| CPU | Model, Max clock ({n} MHz) | Topology, Vendor, Architecture, L3 cache, Virtualization |
| Memory | Total | Per-DIMM modules: Size, Type, Speed, Part number, Manufacturer, Serial |
| Graphics | One row per GPU | — |
| Storage identifiers | Per internal drive (device node as subtitle): Model, Serial — plus RAID members | External drives appear; per drive adds WWN, NGUID, Firmware, Power-on hours |
RAID / HBA — {vendor} | Controller, Members ({n} physical drive(s)), per-member Model / Size / Media / Serial | Per-member Health (SMART OK/FAIL · hours · reallocated) |
| Battery | Name, Health {n}%, Capacity ({full} Wh now / {design} Wh design) | Charge, Power, Voltage, Cycles, Chemistry, Manufacturer, Mfg date |
| Displays | Type (Touch / Non-touch), WFC (Yes / No) | Per-connector EDID: Model, Manufacturer, Product code, Year |
| Network | (Advanced only) | Wi-Fi adapter; per-interface State, Speed, MAC |
| Webcam | (Advanced only) | Detected camera devices |
| USB devices | (Advanced only) | Enumerated USB devices |
| Bluetooth | (Advanced only) | Adapter detection |
| Fan & temp | (Advanced only) | Fan and thermal sensor readings |
| AC adapter | (Advanced only) | Power adapter details |
The Battery health percentage is color-graded: good at 80% or above (green), fair at 50–79% (amber), poor below 50% (red). "WFC" in the Displays section is the world-facing camera flag.
Storage devices
Below the spec sections, the storage component lists every disk — internal drives first, then external. Each drive shows:
- Model, Transport, and Serial
- Size in decimal units (
256 GB,1.0 TB) - Used —
{used}/{total} ({pct}%), orunavailablewith the explanationencrypted, hibernated, or unsupported filesystem - Health — a SMART-derived verdict:
failing(red),degrading(amber),healthy(green), orstatus n/a. The verdict's detail line assembles what the drive reports:{n}% life used,{X} powered on, reallocated/pending/uncorrectable sector counts, temperature in °C, and total data written. - Wipe target — eligible (green), or excluded (muted) with the reason.
The exclusion reasons, verbatim:
| Reason | Why |
|---|---|
hosts the running OS / boot or live boot medium | The drive is mounted at /, a boot path, a media mount, or is the live boot medium itself. |
removable device | The drive reports itself as removable. |
removable transport (usb|mmc) | The drive is attached over USB or an SD/MMC slot. |
network/SAN transport (iscsi|fc|fcoe) | The drive is a network or SAN volume, not local media. |
A drive that merely carries a mounted secondary data filesystem remains a valid wipe target — only OS/boot/live and removable/network media are excluded. Exclusion is enforced again on the Drives screen: excluded drives are listed there but cannot be selected.
Where the data goes
Once the device is verified and collection has settled, the engine sends the complete fingerprint — every section above, verbatim, with internal drives only in the storage list — to your account with POST /api/record, once per boot. The web app upserts one asset per physical machine, so re-booting the same laptop updates its record rather than duplicating it. Browse the results in Inventory; see Booting & verification for the report's timing and retry behavior.
The nine hardware tests
The Test screen (band title Hardware tests) lists nine functional tests. Run any test individually, or use the audit control at the top:
- Idle:
▶ Start Audit, captioned "runs every test top-to-bottom automatically". - Running:
■ Stop Audit, with progressrunning audit — test {n} of 9.
Starting an audit clears all prior results — an audit is a fresh grading pass, never a patch on old ones.
Each test row shows a verdict: — (not run), running…, Passed (green), or Failed (red). The battery row shows its detail instead of a bare verdict — for example 84%, NULL, or 100% (uncalibrated gauge).
Absent hardware fails its test. A machine with no Wi-Fi adapter cannot be sold as having one, so the Wi-Fi test on such a machine records a Fail, not a skip. The same holds for every detection test. This keeps the test record an honest statement of what the machine has, not just what happened to respond.
Keyboard (keyboard)
Opens fullscreen and captures raw keyboard input directly from the input devices — so it sees every key, including ones the OS would normally swallow. The instruction reads: Press every key — each lights up. Press Alt + Esc for the Pass / Fail menu. A banner tracks progress: {hit}/{total} keys · raw capture active ({n} device(s)). Because capture is raw, the only way out is the advertised chord: Alt + Esc opens a menu with Pass, Fail, and Close.
Display (display)
Fills the screen with solid colors, switched with the number keys 1–9: White, Black, Red, Green, Blue, Cyan, Magenta, Yellow, Gray. Press Esc to finish, which asks: Did the panel render every color cleanly, with no dead pixels or backlight defects? with Pass, Fail, and Resume options.
Touchscreen (touchscreen)
Fullscreen grid of 14×9 = 126 tiles. Swipe across the panel to light every tile; the test auto-passes the moment all 126 are lit — no menu needed.
Webcam (webcam)
Shows a live in-page camera preview labeled live · {w}×{h}, with a camera switcher when more than one camera is present, and Pass / Fail / Close buttons. On machines whose cameras sit behind an Intel IPU/MIPI pipeline (Microsoft Surface devices, notably), a live stream isn't possible on this platform — the test shows Camera detected — stream unavailable on this platform and records that outcome automatically. Detection detail: detected: {nodes}.
Audio (audio)
Two checks in one panel: a ▶ Play test tone button that plays a 1-second 440 Hz tone through the speakers, and a Microphone level bar with the instruction "speak or tap the mic — the bar should move". Grade with Pass / Fail / Close.
USB Ports (usb_ports)
Detection test: reports {n} USB device(s) enumerated. Plug a device into each port and re-check to exercise all of them.
Battery (battery)
Automatic grading from the battery's own gauge:
- State of health: ≥80% is Good, ≥50% is Fair, below is Poor.
- Cycle count: ≥1500 cycles grades Poor, ≥1000 grades Fair.
- The test fails when the grade is Poor, or when the gauge reports no reading (
NULL).
The row's verdict shows the detail itself — e.g. 84%, or 100% (uncalibrated gauge) when the reading looks implausible.
WiFi Adapter (wifi_adapter)
Detection test: detected: {ifaces} on success, no wireless adapter on failure — which, per the philosophy above, is a Fail.
Bluetooth (bluetooth)
Detection test, same shape as Wi-Fi: reports the detected adapter, fails when none exists.
Test results on the asset record
Every time the test grid changes and settles, the engine pushes a full snapshot of all nine tests to your account with POST /api/tests, keyed to this boot's record_id:
Snapshot
{
"record_id": "CW-20260623-221305",
"tests": {
"keyboard": { "status": "passed" },
"display": { "status": "passed" },
"battery": { "status": "passed", "detail": "84%" },
"wifi_adapter": { "status": "failed", "detail": "no wireless adapter" },
"touchscreen": { "status": "not_started" }
}
}
Each test's status is one of not_started, passed, or failed, with an optional detail string. Because every push is a complete snapshot, the asset page in Inventory always shows the latest full picture — re-running a test simply updates its row.
Operator notes
The Notes toggle in the header band opens a 320px panel on the right of every screen (hint text Notes) where the operator records anything about the machine — cosmetic condition, missing parts, lot references. Notes autosave: 1.5 seconds after you stop typing, on leaving the field, and on closing the panel. They are sent fire-and-forget with POST /api/notes, keyed to the same record_id, and appear on the machine's asset page alongside the fingerprint and test results. Notes are blocked while the device is locked, since there is no verified record to attach them to.