Auditointia ei pidä lisätä jälkikäteen
Kansio, joka saapui liian myöhään
Kokoushuoneessa oli tavanomaiset institutionaalisen vakavuuden merkit: lasiseinät, kahvinkeitin, joka teki parhaansa paineastian vaikutelmasta, sekä jaetulla näytöllä oleva kansio nimeltä evidence pack. Tarkastelun kohteena ollut järjestelmä oli ollut tuotannossa yhdeksän kuukautta. Se reititti sisäisiä tapauksia, suositteli seuraavia toimenpiteitä, nosti osan niistä asiantuntijoille ja hylkäsi muita hiljaa, koska määritetyt raja-arvot niin sanelivat. Kukaan huoneessa ei kuvannut sitä suuririskiseksi järjestelmäksi hankinnan aikana. Se oli tuottavuustyökalu, joksi organisaatiot kutsuvat päätösinfrastruktuuria ennen kuin kukaan kysyy, keihin se vaikutti.
Auditoija esitti pienen kysymyksen. Tässä tapauksessa, mikä politiikkaversio oli voimassa, kun suositus tuotettiin. Tuoteomistaja katsoi arkkitehtia. Arkkitehti katsoi data-asiantuntijaa. Data-asiantuntija avasi kojelaudan, sitten lokiviennin, sitten tiketin. Eräs kehittäjä muisti, että politiikkaversiot oli ensimmäisessä julkaisussa tallennettu ympäristömuuttujaan ja tammikuun siirron jälkeen tietokantatauluun. Joku sanoi, että muutos oli todennäköisesti vaaraton. Tämä on harvoin se lause, joka saa auditoijan rentoutumaan.
Mitään ei ollut rakennettu pahassa tarkoituksessa. Tiimillä oli lokit, seuranta, käyttöoikeushallinta, varmuuskopiot, häiriötiketit ja sisäinen wiki, jossa oli tarpeeksi sivuja vahingoittamaan tulostinta. Mutta todisteet eivät olleet järjestelmän ominaisuus. Ne olivat jälkikäteen suoritettu rekonstruointiharjoitus ihmisten toimesta, jotka vielä muistivat käyttöönoton. Se ei ole auditoitavuutta. Se on suullista historiaa aikaleimoilla.
Auditoitavuutta ei pitäisi lisätä myöhemmin, koska myöhemmin on juuri se hetki, jolloin muistista on tullut poliittista. Ihmiset ovat hermostuneita. Järjestelmä on muuttunut. Toimittajat ovat vaihtuneet. Kojelaudat on suunniteltu uudelleen. Se ainoa insinööri, joka ymmärsi alkuperäisen datatuonnin, on nyt eri tittelin alla ja puhuu siitä ajasta tyynesti kuin putkivahingon selvinnyt. Jos tietoa ei luotu silloin, kun työ tapahtui, myöhempi kertomus sisältää aina enemmän tulkintaa kuin todisteita.
Auditoitavuus on suunnitteluominaisuus
Monet tiimit kohtelevat auditoitavuutta dokumentaationa. He kuvittelevat sen kaavioiden, kontrollien, hyväksyntöjen, vientipainikkeiden ja politiikkalauseiden kokoelmaksi, joka voidaan koota, kun järjestelmä on lähellä julkaisua. Tämä näkemys on houkutteleva, koska dokumentaatio tuntuu halvemmalta kuin suunnittelu. Se antaa projektin jatkua, kun hallinto odottaa kohteliaasti käytävällä leikepöydän kanssa. Lasku saapuu myöhemmin korkoineen.
Auditoitavuus on lähempänä kestävyyttä kuin dokumentaatiota. Kestävä järjestelmä ei muutu kestäväksi siksi, että joku kirjoittaa raportin, jonka mukaan katto todennäköisesti kestäisi sateen. Katto joko johtaa veden pois tai ei johda. Auditoitava järjestelmä joko säilyttää tosiasiat, joita tarvitaan sen käyttäytymisen tarkasteluun, tai ei säilytä. Tosiasiat voivat olla tylsiä: versio, lähde, aikaleima, toimija, sääntö, kynnysarvo, poikkeus, hyväksyntä, mallitunniste, kehotepohja, tietoalue, säilytystila. Tylsyys on hyväksi. Sillankin kannattelevat tylsät osat. Koristevalaisimet eivät ole kuorman kantaja.
Vaikea osuus on se, että auditointitiedot on tallennettava samalla tasolla, jolla päätökset tehdään. Jos työnkulku käyttää käytäntösääntöä, säännön versio kuuluu tapahtumaan. Jos mallin tuotos hyväksytään asiakirja-aineistoon, mallin versio, luottamusväli, lähdealue ja hyväksymissääntö kuuluvat tietueeseen. Jos ihminen ohittaa suosituksen, ohituksen syy kuuluu toiminnon yhteyteen, ei kokousmuistioon kaksi viikkoa myöhemmin. Järjestelmän ei pitäisi vaatia historioitsijaa päättelemään sitä, minkä kone jo tiesi suorituksen aikana.
Tämän vuoksi auditoitavuus ei ole sama asia kuin lokitus. Lokit ovat hyödyllisiä, mutta niiden ensisijainen tehtävä on yleensä käytönvalvonta. Ne selittävät vikoja, ajoituksia, uudelleenyrityksiä, poikkeuksia ja suorituskykyä. Auditoitavuus kysyy erilaisia kysymyksiä: mitä valtuutusta käytettiin, mitä näyttöä harkittiin, mikä tila muuttui, kuka tai mikä sen aiheutti, ja voidaanko järjestys tarkistaa luottamatta nykyiseen palveluun. Lokit voivat tukea tätä työtä. Ne harvoin hoitavat sitä yksin.
Ensimmäinen päätös on se, mikä lasketaan mukaan
Ennen kuin järjestelmä voi olla auditoitava, organisaation on päätettävä, mikä lasketaan auditoitavaksi tapahtumaksi. Tämä kuulostaa hallinnolliselta, mutta juuri tästä todellinen arkkitehtuuri alkaa. Jos jokainen napsautus on tapahtuma, tietueesta tulee kaatopaikka. Jos vain lopulliset tulokset ovat tapahtumia, tietueesta tulee taikatemppu. Hyödyllinen välimaasto on tallentaa hetket, joissa valtuutus, näyttö tai tila vaihtaa omistajaa.
Asian käsittelyyn ottaminen on tällainen hetki. Lähdeasiakirjan saapuminen alueelle on toinen. Mallin suositus on sellainen, jos se voi vaikuttaa työhön. Käytäntöportin laukeaminen on sellainen. Ihmisen hyväksyntä on sellainen. Kieltäytyminen, eskalaatio, poikkeus, tietojen korjaus, säilytyksen muutos, poistopyyntö ja muutoksenhaku ovat kaikki ehdokkaita. Tarkoitus ei ole säilyttää järjestelmän jokaista henkäystä. Tarkoitus on säilyttää liitoskohdat, joissa myöhempi tarkastaja kysyisi aiheellisesti: miksi järjestelmä siirtyi tästä tuonne.
Tämän valinnan on oltava nimenomainen. Muuten tiimi huomaa tarkastuksen aikana, että tärkeä tapahtuma eli kahden komponentin välisessä varjossa. Etupää tietää, että käyttäjä näki varoituksen. Taustajärjestelmä tietää, että asia siirtyi tilaan. Mallipalvelu tietää palauttaneensa pistemäärän. Työnkulkumoottori tietää, että haara valittiin. Mikään yksittäinen tietue ei kerro, että varoitus, pistemäärä, sääntö ja haara kuuluivat samaan päätökseen. Jokaisella on pala maljakkoa. Pöytä on vielä märkä.
Kun tapahtumajoukko on nimetty, insinöörit voivat suunnitella sopimukset sen ympärille. Jokaisella tapahtumalla voi olla pakolliset kentät. Jokaisella kentällä voi olla omistaja. Jokainen skeemamuutos voidaan versioida. Jokainen säilytyssääntö voidaan sitoa lainsäädännölliseen ja toiminnalliseen tarpeeseen. Tämä ei ole järjestelmän vieressä olevaa paperityötä. Se on osa järjestelmän rajaa. Tietueesta tulee työnkulun tuote, ei työnkulun lounaan jälkeen kirjoittama anteeksipyyntö.
Aika ei ole koriste
Auditointityö on pakkomielteistä ajan suhteen hyvästä syystä. Ennen käytäntömuutosta tehty päätös ei ole sama kuin sen jälkeen tehty päätös. Ennen datakorjausta tuotettu mallin tulos ei ole sama kuin sen jälkeen tuotettu. Määräajan jälkeen eskaloidut tapaus on erilainen kuin ennen määräaikaa eskaloidut. Aika ei ole metadataa, jota ripotellaan tapahtumien päälle. Se on osa tapahtuman merkitystä.
Hajautetut järjestelmät tekevät ajasta hankalaa. Kellot ajautuvat. Jonot järjestävät uudelleen. Uudelleenyrityksiä tapahtuu. Työntekijät käsittelevät viestejä myöhässä. Erät ladataan yön yli töillä, jotka nimettiin väliaikaisiksi vuonna 2021 ja ovat nyt kulttuurisesti pysyviä. Jos auditointisuunnittelu olettaa yhden siistin aikajanan, ensimmäinen tapaus opettaa sen toisin. Tämä oppitunti tapahtuu yleensä taulukkolaskentaohjelmassa, joka on kallis luokkahuone.
Auditoitava suunnittelu erottaa tapahtuma-ajan, käsittelyajan, voimassaoloajan ja tarkasteluajan silloin, kun erolla on merkitystä. Tapahtuma-aika kertoo, milloin asia tapahtui liiketoimintaprosessissa. Käsittelyaika kertoo, milloin komponentti käsitteli sen. Voimassaoloaika kertoo, milloin sääntö tai tila tuli voimaan. Tarkasteluaika kertoo, milloin joku myöhemmin tarkasti tai korjasi sen. Nämä erot voivat tuntua nipotukselta, kunnes yksi tapaus ylittää keskiyön, yksi sääntö muuttuu kello 09:00 ja yksi jono tyhjenee hitaasti, koska joku muutti työntekijäpoolin kokoa luottavaisesti ja ilman todisteita.
Sama huolellisuus koskee identiteettiä. Toimija voi olla henkilö, palvelu, agentti, ajastettu työ, valtuutettu käyttäjä tai ulkoinen järjestelmä. Järjestelmän pitäisi kertoa, mikä. Sen ei pitäisi piiloutua pääkäyttäjän taakse, koska siellä integraatiotili asuu. Kun auktoriteetti on valtuutettu, valtuutuksen pitäisi olla näkyvissä. Kun palvelu toimii automaattisesti, omistavan palvelun ja säännön pitäisi olla näkyvissä. Auditointikelpoisuus vaatii nimetyn vastuun, vaikka nimi ei olisi ihminen.
Rekonstruktio ei ole toistoa
Kun tiimit lisäävät auditointikelpoisuuden myöhään, ne tyytyvät usein rekonstruktioon. Ne keräävät lokit, tietokantaotokset, tiketit, chat-viestit ja julkaisutiedot. Ne rakentavat uskottavan aikajanan. Joskus aikajana on oikea. Joskus se on hyvin siisti fiktio vilpittömine kirjoittajineen. Ongelma ei ole se, että ihmiset valehtelevat. Ongelma on se, että rekonstruktio pyytää ihmisiä täyttämään aukkoja paineen alla, ja instituutiot ovat erittäin hyviä saamaan aukot näyttämään tarkoituksellisilta, kun johtoryhmän kokous on alkanut.
Replay on erilainen standardi. Replay tarkoittaa, että järjestelmä säilytti riittävästi jäsenneltyä historiaa, jotta sekvenssin voi käydä läpi uudelleen. Se ei tarkoita, että alkuperäinen malli on kutsuttava uudelleen tai että kaikki ulkoiset riippuvuudet voidaan herättää henkiin. Se tarkoittaa, että tallenteesta näkyy, mikä syöte hyväksyttiin, mikä sääntöversio laukesi, mikä tulos tuotettiin, mikä toimenpide tehtiin ja mikä tila syntyi. Tarkastajan pitäisi pystyä tutkimaan ketjua luottamatta siihen, että nykyinen sovellus kertoo imartelevan tarinan nuoremmasta itsestään.
Replay muuttaa insinöörityön käytäntöjä. Jos tiimi tietää, että päätökset voidaan toistaa, politiikan piilottaminen koodipolkuihin, joiden nimet ovat kuin helper2, vaikeutuu. Kynnysarvojen annetaan harvoin ajautua ilman, että kirjataan, kuka ne muutti. Prompt-pohjia on vaikeampi kohdella kannettavan tietokoneen paikallisina käsityöesineinä. Replay edellyttää, että jokainen merkityksellinen toimenpide kantaa oman kontekstinsa. Tämä on ärsyttävää samalla tavalla kuin turvavyöt: enimmäkseen ennen kolari.
Replay mahdollistaa myös hallinnon rutiininomaisuuden. Sen sijaan, että odotetaan tapausta, tiimit voivat poimia otoksia, tutkia ketjuja, vertailla tuloksia eri politiikkaversioiden välillä ja havaita puuttuvia tallenteita. Auditointijäljestä tulee jotain, jota organisaatio käyttää, ei jotain, jota se tuottaa vain nurkkaan ajettuna. Tämä ero on merkityksellinen. Valvontatoimilla, joita harjoitetaan vain pelon vallitessa, on tapana olla koristeellisia.
Kustannus, kun se lisätään myöhemmin
Myöhäinen auditoitavuus haisee hyvin tunnistettavalta. Se haisee uusilta taulukoilta, joiden nimet ovat kuin audit_log_final. Se haisee data-exportilta, jossa on useimmat sarakkeet, mutta ei niitä, jotka liittyvät kysymykseen. Se haisee konsultilta, joka kysyy, onko olemassa totuuden lähdettä, ja saa kiertokäynnin viidessä järjestelmässä. Se haisee ennen kaikkea tarkoitusten käänteisestä selvittämisestä sivuvaiikutuksista.
Suora kustannus on insinöörityön aika. Tiimien on tunnistettava, missä päätökset tapahtuivat, lisättävä tapahtumien tallennus, täytettävä historialliset tallenteet, paikattava aukot, dokumentoitava oletukset ja rakennettava export-pinnat. Tämä työ osuu usein siihen vaiheeseen, kun järjestelmä kantaa jo käyttäjiä, tapauksia, ominaisuuspyyntöjä ja odotuksia. Epäsuora kustannus on pahempi: luottamus heikkenee. Jos organisaatio ei pysty vastaamaan peruskysymyksiin omasta järjestelmästään, jokaiseen myöhempään vastaukseen suhtaudutaan epäluuloisesti, myös oikeisiin.
Suunnittelulla on myös hintansa. Kun järjestelmä on rakennettu ilman jäljitettävyyttä, sen rajat eivät välttämättä vastaa todisteiden tarpeita. Päätös voi jakautua useiden komponenttien kesken. Tila voidaan korvata sen sijaan, että sitä lisättäisiin. Syyt voidaan laskea näyttöä varten, mutta niitä ei tallenneta. Mallin syötteitä voidaan muunnella ja hylätä. Ihmisen tekemät ohitukset voivat elää kommenteissa. Jäljitettävyyden lisääminen jälkikäteen muistuttaa tällöin vähemmän ikkunan lisäämistä ja enemmän sen huomaamista, että seinä on kantava.
Kustannus ei ole vain tekninen. Myöhäinen jäljitettävyys synnyttää poliittisia väittelyitä siitä, mitä oikeasti tapahtui. Ihmiset puolustavat tiimejään. Toimittajat puolustavat rajapintojaan. Esimiehet puolustavat lanseerauspäätöksiään. Kaikista tulee harrastelijafilosofeja kausaliteetista. Tämä on ymmärrettävää ja enimmäkseen hyödytöntä. Hyvä tallenne vähentää persoonavetoiseen totuuteen turvautumista. Se antaa organisaatiolle mahdollisuuden väitellä politiikasta ja parannuksista sen sijaan, että se väittelisi siitä, onko menneisyys olemassa.
Hyvät tallenteet eivät ole valvontateatteria
On olemassa perusteltu pelko siitä, että jäljitettävyydestä tulee valvontaa. Jotkut organisaatiot kuulevat sanan tallenna kaikki ja toimivat kuin jokainen inhimillinen epäröinti ansaitsisi aikaleiman. Se ei ole jäljitettävyyttä. Se on institutionaalista ahdistusta, johon on liitetty tallennustilaa. Hyvä auditointisuunnittelu on valikoivaa, oikeasuhtaista ja sidottua merkityksellisiin muutoksiin. Se tallentaa valtuudet ja tilan, ei yksityistä kohinaa.
Työntekijöille erolla on merkitystä. Operaattorin, joka hyväksyy poikkeuksen, pitäisi odottaa hyväksynnän tallentuvan. Hänen ei pitäisi odottaa, että jokainen kursorin liike tulee osaksi pysyvää moraalinäytelmää. Asiantuntijan, joka ohittaa mallin suosituksen, pitäisi jättää syykoodi ja huomautus silloin, kun päätös vaikuttaa tapaukseen. Häntä ei pitäisi rangaista siitä, että hän on eri mieltä automaation kanssa, joka oli alun perinkin epävarma. Jäljitettävyyden pitäisi tehdä ammatillisesta harkinnasta näkyvää, ei tehdä ammattilaisista arkoja.
Kansalaisille, asiakkaille, potilaille tai opiskelijoille jäljitettävyyden pitäisi tukea oikeuksia. Sen pitäisi mahdollistaa päätöksen selittäminen, virheellisen tiedon korjaaminen, lopputuloksen haastaminen, poiston todistaminen tai sen osoittaminen, että lähdettä ei käytetty. Tallenne, joka suojaa vain organisaatiota, on puutteellinen. Jäljitysketjusta ei pitäisi tulla yksisuuntaista peiliä. Jos järjestelmä vaikuttaa ihmisiin, tallenteen pitäisi auttaa vastaamaan myös heidän aiheellisiin kysymyksiinsä.
Tässä kohtaa tietojen minimointi ja jäljitettävyys kohtaavat. Ratkaisu ei ole säilyttää kaikkea ikuisesti. Ratkaisu on säilyttää oikeat tosiasiat oikean ajan, selkeän tarkoituksen, käyttösääntöjen sekä poisto- tai säilytyslogiikan kanssa. Niukka ja hyvin jäsennelty tallenne on usein kunnioittavampi ja hyödyllisempi kuin valtava kasa kerättyä jätevirtaa. Kasa tuntuu turvalliselta, kunnes joku kysyy, mitä se sisältää. Sitten siitä tulee vastuu, jossa on hakutoiminto.
Riskirekisterin pitäisi keskustella tapahtumaskaeman kanssa
Riskirekisterit elävät usein hallintodokumenteissa, kun taas tapahtumaskaemat elävät ohjelmistokehityksen repositorioissa. Tämä erottelu on kätevää ja vaarallista. Riskirekisteri sanoo, että on olemassa luvattoman eskalaation riski. Tapahtumaskaeman pitäisi siksi tallentaa, kuka eskalaation teki, minkä valtuuden nojalla, mistä tilasta mihin tilaan ja oliko eskalaatio automaattinen vai manuaalinen. Jos kaavio ei tallenna näitä tosiasioita, kontrolli on toiveajattelua. Toiveet ovat halvempia kuin kontrollit, mikä selittää niiden suosion.
Sama koskee malliriskiä. Jos rekisteri sanoo, että matalan luottamuksen suositukset on tarkistettava, järjestelmän pitäisi tallentaa luottamus, kynnysarvo, tarkistusvaatimus, tarkistaja, lopputulos ja syy julkaisulle tai kieltäytymiselle. Jos rekisteri sanoo, että lähdealueella on merkitystä, tapahtumien pitäisi tallentaa lähdealue. Jos säilytys on riski, tapahtumien pitäisi tallentaa säilytyksen tilan muutokset. Riskirekisterin ei pitäisi olla proosaa, joka leijuu ohjelmiston yläpuolella. Sen pitäisi olla joukko väitteitä, joiden todenperäisyyttä suoritusaika voi auttaa varmistamaan.
Tämä ei tarkoita, että jokainen hallinnointivaatimus muuttuisi välittömästi koodiksi. Jotkin kontrollit ovat inhimillisiä, sopimuksellisia tai organisatorisia. Mutta myös inhimilliset kontrollit tarvitsevat todisteita. Manuaalinen tarkistus voi silti luoda merkinnän. Sopimusvelvoite voi silti kartoittua vaadittuun vakuutukseen. Toimittajan prosessia voi silti kuvata vastaanotettu tapahtuma, allekirjoitettu raportti tai puuttuvan todisteen tila. Tarkoitus on yhdistää riskikieli todistekieleen ennen kuin järjestelmä alkaa tuottaa seurauksia.
Hiljainen hyöty on parempi keskustelu. Insinöörit lakkaavat kuulemasta hallinnoinnista myöhäisen vaiheen moitteena. Hallinnointitiimit lakkaavat kuulemasta suunnittelusta reunatapausten juhlana. Molemmat voivat katsoa samaa tapahtumakaaviota ja kysyä, sisältääkö se riskin hallintaan tarvittavat tosiasiat. Tämä on vähemmän näyttävää kuin tekoälystrategiatyöpaja. Se tuottaa myös epätodennäköisemmin PDF:n, jota kukaan ei voi operationalisoida.
Auditoitavuus muuttaa rakentamiskeskustelua
Kun auditoitavuus on läsnä alusta alkaen, suunnittelukatselmuksista tulee konkreettisempia. Tiimi ei kysy vain, toimiiko ominaisuus. Se kysyy, minkä merkinnän ominaisuus jättää. Se kysyy, kuka voi tarkastaa merkinnän, kuinka kauan se säilyy, mitä voidaan korjata, mitä ei saa koskaan ylikirjoittaa ja mihin tulevaan kysymykseen sen pitäisi pystyä vastaamaan. Nämä kysymykset parantavat ominaisuutta, koska ne paljastavat piilotetun tilan ja epäselvän valtuutuksen.
Myös hankinta muuttuu. Sen sijaan että toimittajilta kysyttäisiin, tukevatko ne auditointilokeja, mihin lähes kaikki voivat vastata iloisesti kyllä, organisaatio voi pyytää tiettyjä todistusominaisuuksia. Voidaanko käytäntöversiot viedä mukaan kunkin päätöksen kanssa. Voidaanko mallitunnisteet ja lähdealueet sisällyttää. Voidaanko inhimilliset ohitukset erottaa automatisoiduista toimista. Voidaanko merkintöjä säilyttää, poistaa, allekirjoittaa tai toistaa sääntöjemme mukaisesti. Voimmeko tarkastaa jäljen maksamatta sankarillisesta ammattipalveluseikkailusta. Viimeinen kohta on usein se, jossa huone muuttuu opettavaiseksi.
Myös operaatiot muuttuvat. Häiriötilanteisiin vastaamisesta tulee vähemmän spekulatiivista. Tiimi voi tunnistaa vaikuttaneet tapaukset, verrata niitä tunnettuihin käytäntöversioihin, löytää puuttuvat merkinnät ja näyttää polun signaalista toimeen. Vaatimustenmukaisuustyöstä tulee vähemmän kausiluonteista. Tuotekehityksestä tulee rehellisempää, koska tiimi näkee paitsi mitä järjestelmä teki, myös missä olosuhteissa se sen teki. Auditoitavuus ei ole jarru toimitukselle. Se on yksi niistä asioista, jotka estävät toimitusta muuttumasta tulevaksi kaivaukseksi.
Mikään tästä ei tee järjestelmästä täydellistä. Auditoitava järjestelmä voi silti tehdä huonoja päätöksiä. Se voi edelleen sisältää huonoa politiikkaa, käyttää heikkoa dataa tai olla sellaisten ihmisten operoima, joilla on hyvin inhimillinen tiistai. Auditointi ei takaa viisautta. Se takaa, että instituutiolla on paremmat mahdollisuudet nähdä, mitä tapahtui, oppia siitä ja osoittaa, ettei se yksinkertaisesti keksinyt vastausta jälkikäteen.
Opetus
Keskeinen virhe on uskoa, että auditointi kuuluu loppuun, koska auditoinnit tehdään lopussa. Ne eivät kuulu. Auditoinnit tapahtuvat seurausten jälkeen, mutta auditoitavuuden on oltava olemassa ennen seurauksia. Tallenteen on synnyttävä toiminnan mukana. Tapahtuman on kannettava kontekstinsa silloin, kun konteksti on vielä totta. Järjestelmän on säilytettävä ero faktan, päätelmän, politiikan, ohituksen ja korjauksen välillä.
Tämä ei ole vaatimus raskaasta prosessista jokaisen pienen työkalun ympärillä. Se on vaatimus oikeasuhteisuudesta. Mitä enemmän järjestelmä muuttaa oikeuksia, pääsyä, rahaa, turvallisuutta, kelpoisuutta, työmäärää tai institutionaalista muistia, sitä enemmän sen on jätettävä rakenteellista näyttöä. Aloita seurauksellisista rajoista. Nimeä tapahtumat. Versioi säännöt. Säilytä aika ja identiteetti. Tee korjauksista additiivisia. Testaa toisto, ennen kuin pelko astuu huoneeseen.
Tässä kurinalaisuudessa on jotakin lähes koominsta. Luotetun automatisoinnin tulevaisuus riippuu vähemmän häikäisevästä älykkyydestä kuin siitä, että muistetaan, mikä sääntö laukesi märkänä keskiviikkona helmikuussa. Mutta vakavat instituutiot rakentuvat tuollaisesta muistista. Ne eivät luota järjestelmiin siksi, että järjestelmät kuulostavat itsevarmoilta. Ne luottavat järjestelmiin, koska järjestelmiä voidaan tarkastaa, kun itsevarmuus ei enää riitä.
Lisää siis näyttö, kun työ on vielä tavallista. Ennen julkaisujuhlia, ennen tapausta, ennen migraatiota, ennen kuin tiimi unohtaa, miksi se kenttä oli valinnainen. Myöhemmin tulee. Myöhemmin tulee aina, mukanaan kansio nimeltä evidence pack ja kysymys, joka ansaitsee paremman vastauksen kuin luultavasti.