Auto-Grade: A Button, Not a Memo
How the auto-grade engine combines defects into an A-R grade — and what the tester still has to confirm.
Shared grading rules keep two testers from turning the same laptop into two different letters. One dent on a lid should not become “minor cosmetic” for one tester and “moderate cosmetic” for another when the buyer, the settlement, and the invoice all depend on that difference.
The auto-grade engine doesn't replace the tester. It removes the part of the tester's job that depends on remembering which corner of which severity matrix the dent on the lid lives in.
How it computes
The engine combines four sub-grades — functional (F0–F3), cosmetic (C0–C4), battery (B0–B3), data-erasure (D0–D3) — into the overall A-R letter using tenant-defined weights. Default weights: cosmetic 30%, functional 50%, battery 20%. Critical defects (anything tagged severity 4) force a minimum of D regardless of the math, because no amount of "but it boots" rescues a laptop that smells like burnt capacitors.
The tester’s side of the deal
The tester picks the defects from a structured list (44 defect codes, 17 zones, 4 severities). The engine suggests the F-grade and the B-grade based on the picks. One click in the tester UI applies the suggestion to the asset and writes the audit row. The tester is still the decision-maker — but the typing-from-scratch step is gone. On a queue of 200 laptops, that's not a small saving.
Where the criteria live
The grading rules sit in tenant settings — not in code, not in a Notion doc. Edit the cosmetic-severity matrix once, and every tester from that point forward grades against the new matrix. The previous version is preserved on every asset that was graded under it, so a buyer who disputes a grade six months later can see the exact criteria that applied at the time.