Auto-grade: un bouton, pas un memo

Des règles de grading partagées évitent que deux testeurs transforment le même laptop en deux lettres différentes. Une bosse sur le capot ne doit pas devenir “minor cosmetic” pour l’un et “moderate cosmetic” pour l’autre quand l’acheteur, le settlement et la facture dépendent de cet écart.

L'auto-grade engine ne remplace pas le tester. Il supprime la partie du travail qui dépend de la mémoire: savoir dans quel coin de quelle severity matrix se trouve la bosse sur le capot.

Comment il calcule

L'engine combine quatre sub-grades — functional (F0–F3), cosmetic (C0–C4), battery (B0–B3), data-erasure (D0–D3) — en une lettre globale A-R selon des tenant-defined weights. Default weights: cosmetic 30%, functional 50%, battery 20%. Les critical defects (tout ce qui est severity 4) imposent un minimum de D quel que soit le calcul, parce qu'aucun "mais il démarre" ne sauve un laptop qui sent le condensateur brûlé.

Le côté tester

Le tester sélectionne les defects dans une liste structurée (44 defect codes, 17 zones, 4 severities). L'engine suggère le F-grade et le B-grade sur base des choix. Un clic dans la tester UI applique la suggestion à l'asset et écrit l'audit row. Le tester reste le décisionnaire — mais l'étape de saisie depuis zéro disparaît. Sur une queue de 200 laptops, ce n'est pas un petit gain.

Où vivent les critères

Les grading rules vivent dans les tenant settings — pas dans le code, pas dans un doc Notion. Modifiez la cosmetic-severity matrix une fois, et chaque tester grade ensuite selon cette nouvelle matrix. La version précédente est conservée sur chaque asset gradé avec elle, afin qu'un buyer qui conteste un grade six mois plus tard puisse voir les critères exacts applicables à ce moment-là.