Auto-grade: ein Button, kein Memo
Wie die Auto-grade Engine Defects zu einem A-R Grade kombiniert - und was der Tester weiterhin bestaetigen muss.
Gemeinsame Grading-Regeln verhindern, dass zwei Tester aus demselben Laptop zwei verschiedene Buchstaben machen. Eine Delle im Deckel sollte nicht fuer den einen Tester “minor cosmetic” und fuer den anderen “moderate cosmetic” sein, wenn Buyer, Settlement und Rechnung von diesem Unterschied abhaengen.
Die auto-grade engine ersetzt den tester nicht. Sie entfernt den Teil der Arbeit, der davon abhängt, auswendig zu wissen, in welche Ecke welcher severity matrix die Delle im Deckel gehört.
Wie sie rechnet
Die engine kombiniert vier sub-grades — functional (F0–F3), cosmetic (C0–C4), battery (B0–B3), data-erasure (D0–D3) — zu einem gesamten A-R Buchstaben anhand tenant-defined weights. Default weights: cosmetic 30%, functional 50%, battery 20%. Critical defects (alles mit severity 4) erzwingen mindestens D, unabhängig von der Rechnung, weil kein "aber er bootet" einen Laptop rettet, der nach verbrannten Kondensatoren riecht.
Die Seite des testers
Der tester wählt defects aus einer strukturierten Liste (44 defect codes, 17 zones, 4 severities). Die engine schlägt anhand der Auswahl den F-grade und B-grade vor. Ein Klick in der tester UI übernimmt den Vorschlag für das asset und schreibt die audit row. Der tester bleibt der Entscheider — aber das Tippen von null verschwindet. Bei einer queue von 200 Laptops ist das keine kleine Einsparung.
Wo die Kriterien leben
Die grading rules liegen in tenant settings — nicht im Code, nicht in einem Notion-Dokument. Ändern Sie die cosmetic-severity matrix einmal, und jeder tester graded ab diesem Zeitpunkt gegen die neue matrix. Die vorherige Version bleibt auf jedem asset erhalten, das darunter gegraded wurde, sodass ein buyer, der sechs Monate später ein grade anficht, exakt sehen kann, welche Kriterien damals galten.