Kunskapskartan
Vad ett verktygsanrop är
Skillnaden mellan att svara och att göra ligger i det som lyssnar på begäran.
En modell kan bara producera text. När den sägs använda ett verktyg skriver den ingenting i en databas och skickar inget mejl.
Den producerar en begäran: namnet på en förmåga och de värden begäran ska bära med sig. Begäran lämnas till ett program utanför modellen, och det programmet avgör om anropet ska köras, med vilken behörighet och mot vilket system. Resultatet läggs sedan tillbaka i texten som modellen läser, och modellen fortsätter skriva.
Hela kontrollen finns alltså i skarven mellan begäran och utförande. Det är där en åtgärd kan avvisas, ändras, kräva en människas handling eller skrivas ner.
En modell som ombeds radera något har ingen förmåga att radera. Den kan bara be. Att den ber är därför ingen incident. Att någon körde begäran utan att pröva den är det. Det förklarar också varför en instruktion i systemprompten är fel plats för en spärr: instruktionen ligger före begäran, spärren måste ligga efter den. Frågan till en leverantör är inte vad modellen får göra, utan vem som utför och vad den prövar först.
Så här går det fel
Ett verktyg som uppdaterar en post kopplas in med ärendenummer som argument. Ingen prövar att numret hör till användaren, eftersom modellen är instruerad att bara arbeta i det öppna ärendet.
En handläggare klistrar in ett mejl som råkar innehålla ett annat ärendenummer, modellen tar det numret, och posten uppdateras i fel ärende. Spåret skrivs efter att svaret levererats, och just det anropet fastnade halvvägs. I verksamhetssystemet står en ändring utan avsändare. Ordningen mellan händelse och spår var omvänd, så det som skulle ha stoppat åtgärden kom efter den.
Det här måste någon bestämma
Att varje förmåga som kopplas in beskrivs som en åtgärd i verksamheten och inte som en teknisk funktion: vad den ändrar, i vilket system, och vad som händer om den körs på fel underlag.
Vilka argument som prövas utanför modellen innan anropet körs, alltså format, tillåtna värden, och att den post som pekas ut hör till det ärende användaren arbetar i.
Och ordningen mellan händelse och spår. Skrivs händelsen ner först och resultatet lämnas tillbaka sedan, stoppar en misslyckad skrivning åtgärden. Sker det omvänt kan en åtgärd genomföras utan att lämna spår, och det är just den åtgärden ni helst hade velat se.