9.3 Checklistor

Redo-att-använda-snabbreferenschecklistor. Kopiera en in i er egen process och anpassa den; poängen är täckning, inte exakt formulering.

Checklista för granskning av nytt mätetal (innan ett mätetal läggs till på en instrumentpanel)

Mätetalet har ett namngivet beslut det informerar (ämne 1.1)
Mätetalet är klassificerat som diagnostiskt eller utvärderande, skriftligt (ämne 1.1)
Om incitamentsbelagt, är ett skyddsmätetal definierat samtidigt (ämne 1.2)
Manipulationsvektorn har namngetts: hur skulle ett rationellt team få det här talet att se bra ut utan att förbättra det verkliga utfallet (ämne 1.2)
Mätetalet är klassificerat som insats, output, eller utfall (ämne 1.3)
Mätetalet har en namngiven ägare och ett dokumenterat källsystem och insamlingsmetod (ämnen 1.4, 1.5)
Mätetalet kommer använda en median eller percentil, inte ett genomsnitt, om den underliggande datan är skev (ämne 1.6)
Mätetalet används aldrig för individuell utvärdering, eller den användningen är separat och explicit avslöjad (ämne 1.1)

Instrumentpanelen har en namngiven, specifik publik och beslut (ämne 8.1)
Varje incitamentsbelagt mätetal visas på samma vy som dess skyddsmätetal (ämnen 1.2, 8.1)
Axlar startar vid noll om inte ett uttalat, synligt undantag är dokumenterat (ämne 1.6)
Trend över tid visas, inte ett enda ögonblicksfoto (ämne 1.6)
Instrumentpanelen har en namngiven ägare och en granskningscadens (ämne 1.4)
Ett synligt uttalande deklarerar vad instrumentpanelen inte är för, om relevant (ämne 1.1)
Datakällor har grundläggande hälsokontroller så en trasig pipeline inte tyst visas som aktuell (ämne 1.5)

Syfte och explicita icke-mål kommuniceras innan lansering, inte reaktivt (ämne 8.3)
Människorna som mäts var involverade i mätetalsval (ämne 8.3)
Programmet börjar i bara-diagnostiskt läge, med en åtagen minimum-bevisperiod (ämne 8.3)
Ett snabbt, synligt responsprotokoll existerar för varje framtida missbruksincident (ämne 8.3)
Ett pilotteam har valts som genuint anmälde sig frivilligt, inte ett som mandaterades (ämne 8.5)
Grundläggande styrning (stadga, ägarskap, diagnostisk policy) är på plats innan instrumentering börjar (ämnen 1.4, 8.5)

Postmortem undersöker systemet, inte individen (ämne 6.2)
Allvarlighetsgrad klassificerades mot dokumenterade, standardiserade kriterier (ämne 6.2)
Upptäckts-, bekräftelse-, och lösningstider registreras separat (ämne 6.2)
Åtgärdspunkter är specifika, tilldelade, och spårade till slutförande (ämne 6.2)
Postmortem delas utan fruktan för individuell konsekvens (ämnen 6.2, 8.3)

Varje instrumentpanelsmätetal har testats mot: “skulle ett team som använder tung AI-assistans men producerar inte mer verkligt värde visa en förbättrad avläsning här” (ämne 7.1)
Ändringsfelfrekvens och defektfrekvens granskas vid sidan av varje ökning i AI-assisterad driftsättningsfrekvens eller commit-volym (ämne 7.1)
Granskningskapacitet och -djup övervakas när AI-genererad kodvolym ändras (ämne 7.1)
Läckta defekter taggas efter AI-assistansnivå för att testa, inte anta, om det historiska defektfrekvensförhållandet fortfarande håller (ämnen 7.1, 7.3)
Upptäckningsmetoder motståndskraftiga mot “ser korrekt ut”-defekter (mutationstestning, egenskapsbaserad testning) är på plats för AI-tunga kodvägar (ämne 7.3)
Metrikstadgan har explicit återbesökts och uppdaterats för det här skiftet, inte lämnad att drifta oundersökt (ämnen 1.4, 7.1)

Varje mätetal har fortfarande en namngiven ägare (ämne 1.4)
Minst ett mätetal har pensionerats under den senaste cykeln om det slutade förtjäna sin plats (ämne 1.1)
Femdimensionsmognadsbedömningen har genomförts ärligt, poängsatt efter minimum, inte genomsnitt (ämne 8.4)
Inget mätetal har drivit från diagnostisk till utvärderande användning utan ett explicit, avslöjat beslut (ämne 1.1)
Definitioner har stickprovskontrollerats mot faktisk instrumentering för drift (ämnen 1.2, 2.4, 5.1, 6.2, 6.4)
Utfall-till-output-förhållandet på primära instrumentpaneler har beräknats och granskats (ämne 7.4)