Praktikern

Vad en språkmodell gör

Verktyget slår inte upp ett svar, det skriver en text som ser ut som ett. Varje gång du känner att en egenskap borde ligga i modellen är det en signal att den saknar plats i det du faktiskt råder över: vad som skickas in, vad som får komma ut, vad som loggas och vem som får göra vad.

• Gå igenom era flöden och märk varje utfäst egenskap med var den bärs: i valet av modell, i det som skickas in, i en kontroll av utdata, eller i en behörighet. Gör genomgången före nästa driftsättning och jämför antalet egenskaper som hamnade på valet av modell med noll, eftersom det är den enda platsen där varken du eller någon annan kan visa hur egenskapen upprätthålls.
• Kör samma fall genom lösningen med den modellidentitet ni kör i drift och med den ni skulle byta till, samma antal körningar per fall, och jämför andelen godtagbara svar per fall. Gör mätningen före bytet, eftersom ett byte som mäts efteråt bara kan beskrivas och inte stoppas.
• Kör en uppsättning frågor du vet saknar täckning, tio gånger vardera, och räkna hur ofta lösningen gissar, avstår eller lämnar över till en människa. Fördelningen jämförs med det beteende ni skrivit att lösningen har, och kontrollen körs om varje gång underlag eller instruktion ändras.

Deterministiskt och generativt

Godkännandet av det du bygger kan inte vila på ett prov med ett förväntat utfall per rad, eftersom den egenskap provet vilar på inte finns här. Formen på ditt eget leveransbevis måste därför vara bestämd innan bygget börjar, annars upptäcks formfelet vid leveransen.

• Rita gränsen mellan det deterministiska och det generativa per flöde, steg för steg, och pröva ritningen mot en verklig körning genom att spåra var varje belopp, frist och paragrafhänvisning i utdatan uppstod. Gör provet före driftsättning: varje storhet som formulerades av modellen där ritningen säger uppslagning är en avvikelse mot ritningen och inte en detalj.
• Skriv leveranskriteriet som en andel av fallen i fallsamlingen som ska klara ett angivet villkor, med angivet antal körningar per fall, och skriv det innan bygget börjar. Ett kriterium som formuleras efter den första mätningen är en tolkning av resultatet och inte ett kriterium.
• Klassa varje anmält fel som bugg eller avvikelse innan någon rör lösningen, och för klassningarna i en lista. Följ över tid hur stor andel som är avvikelser: en avvikelse rättas inte utan möts genom att uppgiften flyttas till ett deterministiskt steg eller genom att lösningen får göra mindre, och avvikelser som behandlas som buggar visar sig som rättelser som inte håller.

Varför den hittar på

Påhittet kommer ur samma räkning som de svar som blir rätt, så uppgiften är inte att bygga bort det utan att göra det mätbart. Ett påhitt som ligger nära det riktiga är osynligt i en genomläsning av enstaka svar, och därför måste det räknas i stället för att bedömas.

• Kontrollera varje angiven källhänvisning maskinellt mot att källan finns och innehåller det som påstås, och kör kontrollen över hela fallsamlingen och inte över de svar någon råkar läsa. Andelen hänvisningar som inte går att verifiera jämförs med föregående mätning, och kontrollen körs vid varje ändring av instruktion eller underlag.
• Mät i drift hur många felaktiga svar som anmäls per ärendetyp och period. Ett utfall nära noll jämförs inte med en förväntan om felfrihet utan prövas mot om anmälningsvägen finns i samma vy som svaret, om den syns, och om anmälaren får ett svar, eftersom en väg ingen använder ger samma siffra som en lösning utan fel.
• Skriv ner den felnivå ni arbetar mot per ärendetyp före driftsättning, och mät utfallet mot den nivån i stickprov med ett bestämt antal svar per ärendetyp och period. Nivån är det som gör en förändring läsbar: utan den är varje ny siffra ett resultat.

Hur du märker att svaret är fel

Ett felaktigt svar låter precis som ett riktigt, så det enda som avslöjar det är innehållet och aldrig tonen.

Varför svaret varierar

Variationen är hur systemet fungerar, och den bestämmer formen på varje mätning du gör. Det som ser ut som en förbättring efter en ändring kan vara den spridning som fanns där oavsett.

• Fastställ antalet körningar per fall innan något mäts, och håll talet detsamma före och efter varje ändring. Kontrollen är att du kan lägga två mätningar bredvid varandra och visa samma tal i båda: skiljer de sig i antal körningar är skillnaden mellan dem inte tolkningsbar.
• Kör hela fallsamlingen två gånger i följd med oförändrad lösning och läs av hur mycket måttet rör sig utan att någon ändrat något. Den rörelsen är golvet, och en ändring som flyttar måttet mindre än så har inte visat något. Mät golvet innan den första ändringen prövas, och mät om det när modellidentitet eller underlag byts.
• Ta ett svar ur loggen och kör om det ur det som sparats, alltså indata, inhämtat underlag och inställningar. Kontrollen lyckas när det som gick in går att återskapa i sin helhet, inte när svaret blev identiskt, och den görs medan ingenting har hänt eftersom förmågan behövs första gången ett svar ifrågasätts.

Vad modellen minns

Allt som ser ut som minne är text som sparats och skickas in på nytt.

Personuppgifter i prompten

Gränsen passeras mitt i arbetsdagen, utan att någon fattar ett beslut.

Instruktioner är inte garantier

Varje begränsning lösningen utfäster är antingen en spärr eller en böjelse, och skillnaden syns inte så länge systemet uppför sig. Du är den som placerar dem, vilket gör att du också är den som kan räkna dem.

• Skriv en förteckning över varje begränsning lösningen utfäster och ange för var och en om den bärs av instruktionstext eller av något utanför modellen: en läsrätt som inte finns, ett verktyg som inte är inkopplat, en kontroll av svaret, eller en människa som godkänner. Jämför förteckningen med listan över det ni kallar krav, och behandla varje krav som landar på instruktionstext som en avvikelse att åtgärda före driftsättning.
• Pröva varje begränsning ni kallar krav genom att försöka bryta den med egna försök och inte förberedda, minst tio gånger per begränsning och med olika formuleringar. Utfallet redovisas som antal lyckade försök per begränsning, och ett enda lyckat försök räcker för att flytta begränsningen ur kravlistan. Provet görs innan begränsningen räknas som byggd.
• Kör om samma försök efter varje ändring av systemprompten och efter varje byte av modellidentitet, med samma antal försök som förra gången. En böjelse som höll vid förra mätningen väger annorlunda i ett annat underlag, och det är just det som gör att den inte kan mätas en gång för alla.

Skugg-AI

Varje oköpt lösning är också en oköpt risk.

Determinismstegen

Du gör det här valet varje gång ett nytt beteende ska in, och priset sjunker för varje steg nedåt. Glidningen mot prompttext märks inte i drift, eftersom alla fyra stegen ser likadana ut så länge inget ovanligt händer.

• Placera varje utfäst begränsning på ett av de fyra stegen i en förteckning som går att läsa utan att någon öppnar koden, och räkna hur många som ligger på det nedersta. Talet jämförs med samma tal vid föregående genomgång: rör det sig uppåt över tid har lösningen glidit, och det är glidningen som ska förklaras och inte den enskilda posten.
• Ta upp placeringen som en egen punkt varje gång ett nytt beteende ska in, före bygget, och skriv en motivering när något hamnar på prompttext med besked om vad som hindrar att det flyttas uppåt. En begränsning ingen kan placera ligger i praktiken på det nedersta steget, och det är kontrollens utfall.
• Behandla en modell som granskar en annan modells svar som en bedömning med egen spridning: mät granskarens utfall i band med samma antal körningar per fall som det den granskar, och jämför hur ofta granskaren och en människa gör samma bedömning på samma fall. Utan det talet vet du inte om steget är en kontroll eller ett andra utfall ur samma sorts räkning.

Mät i band, inte i körningar

Det här är formen på varje beslut du fattar om lösningen blivit bättre. Ett enskilt utfall säger bara att det låg någonstans i fördelningen.

• Kör varje fall det bestämda antalet gånger och redovisa resultatet per fall och inte bara som ett samlat mått. Jämförelsen som betyder något är mellan ett fall som faller varje gång och ett som faller ibland: de kräver olika åtgärd, och ett medelvärde döljer skillnaden eftersom de fall som alltid går igenom dränker dem.
• Behandla varje siffra som läggs fram utan antal körningar och spridning som ett enskilt utfall, oavsett vem som lämnar den, och begär om mätningen innan siffran får ligga till grund för ett beslut. Kontrollen görs när siffran kommer och inte när beslutet ska fattas.
• Innan du godkänner något du sett i en förevisning, kör samma fall mot fallsamlingen med det bestämda antalet körningar och jämför andelen godtagbara svar med den bild förevisningen gav. Skillnaden mellan de två talen är måttet på vad en förevisning är värd hos er, och det är värt att känna till före nästa förevisning.

Att godkänna en prompt

Att godkänna en funktion här är att godkänna en lydelse, ett tröskelvärde eller ett villkor, eftersom de är funktionen. Ett godkännande som pekar på ett möte i stället för på en version går inte att pröva i efterhand.

• Begär den text, det tröskelvärde eller det villkor som styr beteendet, i klartext och med versionsbeteckning, innan du godkänner. Kontrollen är att du kan återge med egna ord vad lydelsen gör: kan du inte det saknar du underlag att godkänna på, och det utfallet är lika giltigt som ett ja.
• Ta ett svar ur loggen och gå bakåt till den lydelse som gällde när det lämnades. Provet görs innan lösningen används skarpt, eftersom kopplingen behövs efteråt och då är för sen att bygga.
• Låt inget förslag passera utan utfallet mot fallsamlingen, med antal körningar per fall, jämfört med utfallet för den lydelse som gäller i dag. Ett förslag utan den jämförelsen godkänns inte, oavsett hur liten ändringen ser ut.

En ändring i taget

Två ändringar mellan två mätningar ger en skillnad som inte går att fördela mellan dem i efterhand. Takten kommer inte av att ni gör mer per steg utan av att ett steg är billigt att ta tillbaka.

• Skriv stoppregeln före körningen: vilket mått som avgör och vid vilken gräns ändringen behålls respektive tas tillbaka. Kontrollen är att regeln finns nedskriven före mätningen, eftersom en regel som formuleras efteråt är en tolkning av det resultat som råkade komma.
• Mät mellan två ändringar och inte efter en bunt, och pröva löpande att varje ändring i instruktioner, tröskelvärden och urvalsregler går att ta tillbaka var för sig. Tiden det tar att ta tillbaka en ändring är själva måttet: går den inte att ta tillbaka på kort tid kräver den ett annat arbetssätt, och det ska vara känt före ändringen och inte efter.
• Jämför i slutet av varje arbetsperiod antalet ändringar med antalet mätningar. Är mätningarna färre har ni buntar, och varje bunt är en skillnad ni inte kan fördela mellan de ändringar som ingick i den.

När mer blir sämre

En skärpt instruktion och en tyngre ombyggnad kan båda sänka måttet, och båda fallen är osynliga om mätningen ligger efter bygget. Ordningen mellan mätning och bygge avgör om du får veta något alls.

• Mät ett utgångsläge på den befintliga enkla lösningen mot samma fallsamling som ombyggnaden sedan ska mätas mot, och gör mätningen innan ombyggnaden påbörjas. Utan den siffran finns bara den nya, och en siffra utan jämförelse ser ut som ett resultat.
• Mät varje skärpning av en instruktion mot hela fallsamlingen och inte mot det fall den skulle rätta, och läs resultatet per fall. Skadan uppstår någon annanstans än rättelsen, så en kontroll som bara körs på det anmälda fallet kan inte hitta den.
• Låt det gamla stå kvar tills det nya mätt bättre, och pröva vid varje driftsättning att återgången faktiskt går att göra. Utfallet av det provet är en tid: kan du inte ange hur lång tid en återgång tar har du inte den möjlighet planen förutsätter.
• Begär före en föreslagen ändring besked om vilka mätvärden den väntas röra åt fel håll, och jämför beskedet med utfallet efteråt. Skillnaden mellan förväntan och utfall säger något om hur väl ni förstår lösningen, och den uppgiften finns bara om beskedet lämnades i förväg.

Fallsamlingens ägare

Fallsamlingen är den enda måttstocken i ett arbetssätt där varje beslut fattas på mätning, vilket gör att ett fel i den drar hela arbetet åt fel håll tyst och konsekvent. Du mäter mot den varje dag, så det är du som först kan märka om den mäter något annat än riktighet.

• Gå igenom samlingen fall för fall och märk varje fall med var det rätta svaret kom ifrån: formulerat av den som kan sakfrågan, eller hämtat ur vad lösningen redan svarade. Andelen härledda fall är kontrollens utfall och jämförs med noll, eftersom ett härlett fall mäter oförändrat beteende och inte riktighet.
• Kontrollera att varje redovisad mätning anger vilken version av samlingen den kördes mot, och jämför två mätningar bara när versionerna är desamma. Kontrollen görs när mätningen läggs fram och inte när slutsatsen dras av den.
• Låt ägaren ändra ett fall en gång, tidigt, och mät tiden från beslut om ändring till att nästa mätning körs mot den ändrade samlingen. Tiden jämförs med hur ofta ni mäter: är den längre styrs samlingen i praktiken av den som bygger och inte av den som äger den.
• Lägg varje fel som anmäls i drift till samlingen som ett permanent fall, och stäm av med jämna mellanrum antalet anmälda fel mot antalet nya fall. Skiljer sig talen har samlingen slutat följa det som faktiskt går fel.

Beslutsrätt per sakområde

Tre områden avgörs med olika kunskap: vad ett rätt svar är, var en garanti ska ligga, och om en ändring mättes innan den behölls. En roll som ska godkänna allt möter frågor hon inte kan bedöma, och båda utvägarna ser ut som att någon äger frågan.

• Skriv upp vem som äger vart och ett av de tre områdena, med namn och inte med funktion, och pröva listan mot verkligheten genom att gå igenom de senaste besluten och märka varje beslut med vilket område det hörde till och vem som faktiskt fattade det. Skillnaden mellan listan och genomgången är kontrollens utfall.
• Märk varje ändring med vem som beslutade den och inom vilket område, löpande medan ni arbetar. Pröva märkningen genom att välja ut ett beslut ett halvår tillbaka och försöka knyta det till någon som kunde fatta det: går det inte är märkningen en form utan innehåll.
• Bestäm i förväg vad som gäller när innehåll och arkitektur säger emot varandra, och för anteckning över varje sådan oenighet med hur den avgjordes. Listan jämförs med regeln, och den visar om regeln används eller om frågan avgörs av den som talar sist.

Det reverterade är värt att spara

Ett arbetssätt som bygger på många billiga försök ger fler återtagna lösningar än behållna, vilket betyder att en stor del av kunskapen ligger i det som togs bort. Ett tomrum ser ut precis som en väg ingen har prövat.

• Avsluta varje återtagning med en anteckning i stället för med en borttagning: vad som prövades, vilket mått som avgjorde, och under vilka förutsättningar. Kontrollen är att antalet anteckningar över en period går att jämföra med antalet återtagningar i historiken, och skillnaden mellan talen är det som gått förlorat.
• Pröva varje föreslaget angreppssätt mot det som redan prövats, före bygget, och låt svaret ingå i förslaget. Utfallet är ett av tre: vägen har inte prövats, den prövades under förutsättningar som sedan ändrats, eller den prövades och föll av ett skäl som består. De tre leder till olika beslut.
• Kontrollera att anteckningen anger vilka förutsättningar utfallet vilade på. Det är den uppgiften som avgör om utfallet går att ompröva när underlaget städats eller en modellidentitet bytts, och utan den är anteckningen bara ett nej utan giltighetstid.

Kontextfönstret

Fönstret är ett tak per anrop, och allt du lägger in konkurrerar med det du behöver ha kvar. En tyst trunkering ser ut precis som ett fullständigt svar, vilket gör att den inte kan upptäckas genom att läsa svar.

• Mät hur stor del av anropet som upptas av systeminstruktion, verktygsbeskrivningar, samtalshistorik och inhämtat underlag vid den konfiguration ni kör, och följ hur fördelningen förskjuts när något läggs till. Mätningen görs före varje tillägg och jämförs med föregående mätning, eftersom det är förskjutningen och inte den enskilda andelen som säger något.
• Pröva att systeminstruktion och behörighetsvillkor har garanterad plats genom att fylla anropet till taket med underlag och läsa av vad som föll bort. Utfallet jämförs med den ordning ni beskrivit att lösningen prioriterar i, och provet görs innan lösningen möter verkliga volymer.
• Framkalla en trunkering och jämför vad användaren ser i gränssnittet och vad som står i loggen med vad som faktiskt uteslöts. Ett svar som ser fullständigt ut när underlaget beskurits är kontrollens negativa utfall, och det är det utfallet ni bygger emot.

Varför långa samtal blir sämre

Kvaliteten sjunker gradvis långt innan något tak nås, vilket gör att ett prov med en kort fråga och ett litet underlag inte säger något om hur lösningen beter sig i ett långt samtal. Det är också förklaringen till att verktyget ibland är skarpt och ibland slött utan att någon ändrat något.

• Kör samma fråguppsättning mot ett litet och ett stort underlag, och i ett nystartat respektive långt samtal, med samma antal körningar per fall i alla fyra lägena. Jämför utfallet per fall mellan lägena: skillnaden är måttet på hur mycket lösningen tål, och det talet finns inte om ni bara mäter i det gynnsammaste läget.
• Läs av vilken volym era mätningar körs mot och jämför den med volymen i drift. Skiljer de sig mäter ni ett annat system än det ni driver, och kontrollen görs före ett godkännande och inte efter en anmälan.
• Lägg medvetet in ett ersatt och ett gällande avsnitt om samma sak i underlaget och kör frågan upprepade gånger. Utfallet är fördelningen mellan de två svaren och inte vilket svar som kom först, och fördelningen jämförs med föregående mätning när underlaget vuxit.

Systemprompten

Systemprompten finns med i varje anrop och styr därför varje svar, och den kan ändras på en eftermiddag utan att något test faller och utan att något bygge misslyckas. Det är du som ändrar i den.

• Förvalta lydelsen i ett versionshanterat förråd och pröva kopplingen genom att ta ett svar ur loggen och slå upp den lydelse som gällde när svaret skapades. Provet görs medan ingenting har hänt, eftersom behovet uppstår efter en invändning och kopplingen då inte går att konstruera i efterhand.
• Jämför den fullständiga text som faktiskt skickas in i ett anrop med den ni tror skickas in, vid varje leverans från den som bygger. Skillnaden mellan de två är instruktionslager ni inte råder över, och den ska vara känd innan en mätning tolkas.
• Kör hela fallsamlingen mot den nya lydelsen före driftsättning, med samma antal körningar som mot den gamla, oavsett hur liten ändringen ser ut. Ändringens storlek säger ingenting om följdens storlek, vilket är skälet att kontrollen inte har någon undre gräns.

Promptinjektion

Det finns ingen teknisk gräns mellan data och instruktion, eftersom det bara finns en text. Så snart lösningen läser något ni inte skrivit själva kan någon annan skriva in i er prompt, och det som avgör följden är vad ni låter systemet göra utan en människas bekräftelse.

• Preparera egna handlingar med instruktioner i löptext, i dold text och i fält som inte visas, och kör dem genom flödet upprepade gånger. Utfallet redovisas per fall som andelen körningar där den injicerade instruktionen följdes, och en enda träff räcker för att flytta åtgärden till en spärr utanför modellen.
• Rita upp var i era flöden extern text möter systemet, och pröva ritningen mot en verklig körning genom att följa varje textkälla som gick in i anropet. Kontrollen görs före driftsättning, och varje källa som fanns i körningen men inte i ritningen är en avvikelse.
• Gå igenom förteckningen över varje åtgärd systemet kan utföra och pröva för var och en om den kan utlösas av innehåll i ett dokument utan en människas bekräftande handling. Resultatet jämförs med listan över åtgärder ni beskrivit som skyddade, och prövningen görs om varje gång en förmåga kopplas in.

Utvärdera en prompt

En ändring i en instruktion är en ändring i systemet, men den kräver ingen utvecklare och ingen driftsättning och görs därför lättvindigt. Fallsamlingen är det enda som skiljer en ändring som hjälpte från en åsikt.

• Kör fallsamlingen före och efter varje ändring i lydelsen, med samma fall, samma antal körningar och samma version av samlingen. Kontrollen är jämförelsen mellan de två körningarna, och ingen av dem betyder något ensam.
• Sätt samman samlingen av de svåra fallen: ärenden med undantag, frågor nära en gräns, underlag där en uppgift saknas, och frågor lösningen inte ska svara på alls. Pröva sammansättningen genom att läsa av hur stor andel av fallen som klaras i varje körning: en samling där nästan allt går igenom varje gång skiljer inte längre två lydelser åt, och det talet är signalen att den ska skärpas.
• Låt resultatet följa med ändringen i historiken och kontrollera vid en stickprovsläsning att det går att se vad som prövades och vad som släpptes igenom. Görs kontrollen först när någon frågar är materialet redan format av vad någon mindes.

Varför datan är flaskhalsen

Taket för hur bra ett svar kan bli sätts av underlaget, innan modellen kommer in i bilden. Det betyder att ingen ändring i instruktionen kan lyfta ett fall där rätt underlag aldrig fanns att hämta.

• Dela varje fall som faller i två grupper innan du ändrar något: de där rätt underlag fanns bland det som hämtades, och de där det inte fanns. Andelen i den andra gruppen är taket för vad promptarbete kan ge, och uppdelningen görs före varje omgång sådant arbete.
• Pröva lösningens läsförmåga mot ett stickprov ur det verkliga beståndet, valt av verksamheten och inte av den som bygger, och redovisa vad den inte kan läsa alls. Utfallet jämförs med den mängd underlag ni antog vara tillgänglig när flödet ritades.
• Kontrollera för varje användningsfall om det som ska besvaras alls finns i text, eller om det sitter som poster i ett verksamhetssystem eller hos erfarna handläggare. Kontrollen görs innan flödet byggs, eftersom ett användningsfall utan underlag inte blir bättre av att byggas färdigt.

RAG

Kvaliteten sitter i söksteget, som är den del ingen förevisar och den del ett modellbyte inte rör. Två steg säljs som ett, och de måste mätas var för sig för att någon ska kunna se vilket av dem som brister.

• Mät söksteget skilt från svaret: räkna för varje fråga i samlingen hur ofta rätt underlag alls fanns bland det som hämtades. Jämför det talet med andelen godtagbara svar, eftersom skillnaden mellan de två talen är vad formuleringssteget lägger till eller förstör.
• Titta på hur ett av era egna dokument med tabeller ser ut efter uppdelningen i avsnitt, innan underlaget görs sökbart, och jämför med källan. En tabell, en blankett eller en paragraf som delats på fel ställe blir obrukbar som underlag utan att det syns i något svar.
• Ändra ett dokument och ställ sedan frågan det besvarar upprepade gånger tills svaret följer med. Tiden anges i timmar eller dagar och jämförs med den tid flödet förutsätter, och mätningen görs om när underlagets storlek vuxit.
• Kör en fråga du vet saknar täckning, upprepade gånger, och räkna hur ofta lösningen säger att underlag saknas i stället för att fylla ut. Det beteendet uppstår inte av sig självt, och andelen är det enda som visar om det är byggt eller bara beställt.

När RAG inte är svaret

Sökningen hämtar ett bestämt antal avsnitt och skickar dem vidare, och ingenting i den mekaniken avgör om frågan var av rätt sort. Systemet svarar ändå, och en siffra i det svaret ser ut som vilken siffra som helst.

• Gå igenom era användningsfall ett i taget och märk vart och ett med var svaret kommer ifrån: sökning i text, eller fråga mot ett system. Kontrollen görs innan flödet byggs, och varje fall som kräver räkning, fullständighet eller aktuell status och ändå ligger på sökning är en avvikelse och inte en avvägning.
• Lägg in frågor av de tre brytande sorterna i fallsamlingen, alltså räkning, fullständighet och aktuell status, och mät hur ofta lösningen avstår i stället för att svara ur ett urval. Andelen jämförs med alla körningar, eftersom ett urval per definition inte kan besvara en fråga som kräver hela mängden.
• Kontrollera att antalet hämtade avsnitt visas för användaren tillsammans med svaret, och pröva i en verklig vy att uppgiften följer med också dit svaret används vidare. En användare som ser att svaret bygger på fem avsnitt läser det annorlunda än en som ser en färdig mening.

Datakvalitet som förutsättning

En sökning ser text och inte status, så ett välskrivet utkast kan slå en gällande riktlinje. Felet ser inte ut som ett fel utan som ett svar, vilket gör att det inte går att hitta genom att läsa svar.

• Inventera det tilltänkta underlaget före driftsättning och redovisa dubbletter, dokument utan angiven ägare och dokument utan datum som en lista med antal. Listan är arbetsunderlaget och inte kvittot: kontrollen är att antalen sjunker mellan två inventeringar.
• Märk ett dokument som ersatt och ställ sedan upprepade gånger den fråga det besvarar. Utfallet är andelen körningar där det ersatta dokumentet ändå blev underlag, och den andelen jämförs med noll. Provet görs innan ni lutar er mot märkningen som ett styrande villkor.
• Lägg in fall i samlingen där ett ersatt och ett gällande dokument säger olika, och håll dem kvar permanent. Kontrollen körs vid varje mätning, eftersom ett städat material börjar dra isär från första dagen och ingen annan signal talar om att det skett.

Vad ett verktygsanrop är

Modellen kan bara be, och hela kontrollen sitter i skarven mellan begäran och utförande. Att modellen ber om något olämpligt är inte en incident, att någon körde begäran utan att pröva den är det.

• Skicka in begäran med värden som inte hör till användarens pågående ärende, upprepade gånger, och räkna hur ofta anropet ändå kördes. Andelen jämförs med noll, och kontrollen görs innan förmågan kopplas in i drift.
• Framkalla en misslyckad skrivning till spåret och läs av om åtgärden stoppades eller genomfördes. Ett utförande som fortsätter när spåret inte kunde skrivas gör åtgärden ospårad, och det utfallet syns inte i normal drift eftersom allt annat ser oförändrat ut.
• Stäng av en enskild förmåga en gång, i en miljö där det går att pröva, och mät hur lång tid det tog. Tiden jämförs med den tid ni förutsatt i planen för vad som händer när något går fel.

Agenter

Agenten väljer sina egna steg, vilket gör att ingen i förväg kan säga vad den kommer att göra. Varje kontroll måste därför gälla utfall över många körningar och inte den sekvens du råkade se.

• Mät hur stor del av anropet verktygsbeskrivningarna upptar vid den konfiguration ni kör, och gör om mätningen varje gång ett verktyg läggs till. Utfallet jämförs med föregående mätning och med det utrymme underlaget behöver, eftersom det ena tas från det andra.
• Kör samma uppdrag genom agenten upprepade gånger och läs av spridningen i antal steg och i valda verktyg. Spridningen jämförs med den bild uppdraget ger av vad agenten borde göra: stor spridning i verktygsval betyder att uppdraget är för brett formulerat, och det syns inte i en enskild körning.
• Sätt ett tak för antal steg och för hur länge agenten får arbeta, och pröva vad som händer när taket nås genom att sänka det tillfälligt och köra. Utfallet jämförs med det beteende ni bestämt, alltså att agenten stannar och säger att den inte kom fram i stället för att pröva en omväg.
• Läs listan över verktyg som hör till uppdraget och pröva om en människa kan säga utifrån den vad agenten kan ställa till med. Är listan för lång för det är det kontrollens utfall, och prövningen görs innan nästa verktyg kopplas in och inte när valen börjar bli fel.

Kedjor och felfortplantning

Kedjan för vidare formen på ett svar utan att föra vidare hur väl det var grundat. Granskar du steg för steg ser allt rimligt ut, eftersom det orimliga bara syns i jämförelsen mellan det som gick in längst fram och det som kom ut längst bak.

• Mät kedjan från ände till ände och inte per steg: jämför det första underlaget med det sista svaret för varje fall i samlingen, upprepade gånger. En stegvis mätning kan inte hitta det fall där varje steg gjorde en rimlig tolkning och helheten blev något ingen hade godkänt.
• Håll ritningen över kedjan mot en verklig körning och kontrollera att varje steg tar emot och lämnar det ritningen säger. Kontrollen görs efter varje ändring i kedjan, eftersom en ritning som inte prövats beskriver vad någon avsåg och inte vad som körs.
• Bär belopp, datum, personnummer och paragrafhänvisningar som egna fält genom kedjan och pröva dem mot källan i sista steget. Utfallet är antalet fall där fältet skilde sig från källan, och det talet jämförs med noll vid varje körning av samlingen.
• Avbryt en kedja med avsikt och jämför vad mottagaren ser med hur ett färdigt resultat ser ut. Ett halvfärdigt resultat som ser färdigt ut är det som passerar en granskning, och det är därför provet måste göras och inte antas.

Vad som måste loggas

Bevisbarhet och återskapbarhet är skilda åtaganden, och en lösning kan visa att en anteckning är orörd utan att kunna visa vad som stod i svaret. Du kan pröva vilket av dem som faktiskt är byggt, och du kan göra det medan ingenting har hänt.

• Begär ett verkligt loggutdrag för ett enskilt ärende och läs det fält för fält mot vad som skulle behövas för att köra om svaret: personen, tidpunkten, den fullständiga inmatningen, det hämtade underlaget, versionerna av modell och instruktion, och det levererade svaret. Kontrollen är att utdraget räcker för en omkörning, inte att loggning finns.
• Framkalla en misslyckad skrivning av loggposten och läs av om svaret ändå lämnades ut. Ett svar som når mottagaren när posten inte kunde skrivas är ospårat, och det utfallet upprepas tyst i drift eftersom ingenting annat avviker.
• Räkna hur ofta de valfria fälten i posten står tomma i ett verkligt utdrag över en period. Ett valfritt fält jämförs inte med sin specifikation utan med sin fyllnadsgrad, och kontrollen görs innan ni räknar fältet som en del av spåret.
• Håll loggens lagringstid och behörighet mot samtalshistorikens och kontrollera att de sattes var för sig. Är de identiska har de sannolikt ärvt varandras inställningar utan att någon valt dem, och det är den jämförelsen som visar det.