Auditálhatóságot nem lehet utólag hozzáadni

Auditálhatóságot nem lehet utólag hozzáadni

A mappa, amely túl későn érkezett

A tárgyalóterem az intézményi komolyság szokásos jeleit mutatta: üvegfalak, egy kávéfőző, amely a nyomástartó edény szerepét igyekezett alakítani, és egy bizonyítékcsomagnak nevezett mappa a megosztott képernyőn. A felülvizsgált rendszer kilenc hónapja működött élesben. Belső eseteket irányított, következő lépéseket javasolt, néhányat szakértőkhöz továbbított, másokat pedig csendben elutasított, mert a beállított küszöbértékek ezt írták elő. A teremben senki sem nevezte magas kockázatú rendszernek a beszerzés során. Ez egy termelékenységi eszköz volt, ahogyan a szervezetek a döntési infrastruktúrát nevezik, mielőtt bárki megkérdezi, kit érintett.

Az auditor egy apró kérdést tett fel. Ehhez az esethez melyik szabályzatverzió volt aktív, amikor a javaslat elkészült. A terméktulajdonos az építészre nézett. Az építész az adatfelelősre nézett. Az adatfelelős megnyitott egy irányítópultot, majd egy naplóexportot, majd egy jegyet. Egy fejlesztő visszaemlékezett, hogy a szabályzatverziókat az első kiadásban egy környezeti változóban tárolták, a januári migráció után pedig egy adatbázistáblában. Valaki azt mondta, a változás valószínűleg ártalmatlan volt. Ez ritkán az a mondat, amelytől az auditor megnyugszik.

Semmi sem készült rossz szándékkal. A csapatnak voltak naplói, megfigyelése, hozzáférés-ellenőrzése, biztonsági mentései, incidensjegyei és egy belső wikije, annyi oldallal, hogy egy nyomtatót is tönkretehetett volna. De a bizonyíték nem a rendszer tulajdonsága volt. Ez egy rekonstrukciós gyakorlat volt, amelyet utólag végeztek el olyan emberek, akik még emlékeztek a telepítésre. Ez nem naplózhatóság. Ez szóbeli történelem időbélyegekkel.

A naplózhatóságot nem szabad később hozzáadni, mert a később pontosan az az időpont, amikor az emlékezet politikussá vált. Az emberek idegesek. A rendszer megváltozott. A beszállítók cserélődtek. Az irányítópultokat áttervezték. Az egyetlen mérnök, aki értette az eredeti adatimportot, most más munkakört tölt be, és arról az időszakról annak a nyugalmával beszél, aki túlélt egy vízvezeték-balesetet. Ha a feljegyzés nem a munka elvégzésekor készült, a későbbi történet mindig több értelmezést tartalmaz majd, mint bizonyítékot.

A naplózhatóság tervezési tulajdonság

Sok csapat dokumentációként kezeli a naplózhatóságot. Úgy képzelik el, mint diagramok, ellenőrzések, jóváhagyások, exportgombok és szabályzati nyilatkozatok halmazát, amelyet össze lehet állítani, amint a rendszer közel kerül a kiadáshoz. Ez a nézet csábító, mert a dokumentáció olcsóbbnak tűnik, mint a tervezés. Lehetővé teszi, hogy a projekt haladjon, miközben a kormányzás udvariasan vár a folyosón egy jegyzettömbbel. A számla később érkezik, kamatostul.

Az auditálhatóság közelebb áll a tartóssághoz, mint a dokumentációhoz. Egy tartós rendszer nem attól válik tartóssá, hogy valaki jelentést ír arról, hogy a tető valószínűleg kibírná az esőt. A tető vagy elvezeti a vizet, vagy nem. Egy auditálható rendszer vagy megőrzi a viselkedése ellenőrzéséhez szükséges tényeket, vagy nem. A tények unalmasak lehetnek: verzió, forrás, időbélyeg, szereplő, szabály, küszöbérték, kivétel, jóváhagyás, modellazonosító, prompt sablon, adatkör, megőrzési állapot. Az unalom rendben van. Egy hidat is unalmas részek tartják. A díszlámpák nem a teherviselő elemek.

A nehéz rész az, hogy az auditálási tényeket ugyanazon a szinten kell rögzíteni, ahol a döntések születnek. Ha egy munkafolyamat szabályt használ, a szabály verziója az eseményhez tartozik. Ha egy modell kimenetét elfogadják egy ügyiratba, a modell verziója, a megbízhatóság, a forrás köre és az elfogadási szabály a nyilvántartásba tartozik. Ha egy ember felülbírál egy javaslatot, a felülbírálás oka a művelet mellé tartozik, nem pedig egy két héttel későbbi értekezleti jegyzetbe. A rendszernek nem szabad megkövetelnie, hogy egy történész következtessen arra, amit a gép futásidőben már tudott.

Ezért az auditálhatóság nem ugyanaz, mint a naplózás. A naplók hasznosak, de elsődleges céljuk általában az üzemeltetés. Hibákat, időzítéseket, újrapróbálkozásokat, kivételeket és teljesítményt magyaráznak. Az auditálhatóság más kérdéseket tesz fel: milyen jogosultságot használtak, milyen bizonyítékot vettek figyelembe, milyen állapot változott, ki vagy mi okozta, és ellenőrizhető-e a sorrend az aktuális szolgáltatás megbízása nélkül. A naplók támogathatják ezt a munkát. Ritkán viszik el egyedül.

Az első döntés az, hogy mi számít

Mielőtt egy rendszer auditálható lehetne, a szervezetnek el kell döntenie, hogy mi számít auditálható eseménynek. Ez adminisztratívnak hangzik, de itt kezdődik a valódi architektúra. Ha minden kattintás esemény, a nyilvántartás szemétlerakóvá válik. Ha csak a végső eredmények események, a nyilvántartás trükké válik. A hasznos középút az, ha azokat a pillanatokat rögzítjük, amikor jogosultság, bizonyíték vagy állapot gazdát cserél.

Az ügy befogadása ilyen pillanat. A forrásdokumentum hatókörbe kerülése szintén az. A modelljavaslat az, ha befolyásolhatja a munkát. Egy szabálykapu lefutása az. Egy emberi jóváhagyás az. Az elutasítás, az eszkaláció, a kivétel, az adatjavítás, a megőrzési változás, a törlési kérelem és a fellebbezés mind jelöltek. A lényeg nem az, hogy a rendszer minden lélegzetvételét megőrizzük. A lényeg az, hogy megőrizzük azokat az illesztési pontokat, ahol egy későbbi felülvizsgáló jogosan kérdezhetné: miért mozdult el a rendszer innen oda.

Ennek a kiválasztásnak explicitnek kell lennie. Különben a csapat a felülvizsgálat során fedezi fel, hogy a fontos esemény két összetevő árnyékában élt. A frontend tudja, hogy a felhasználó látta a figyelmeztetést. A backend tudja, hogy az ügy állapotot váltott. A modellszolgáltatás tudja, hogy pontszámot adott vissza. A munkafolyamat-motor tudja, hogy egy ág lefutott. Egyetlen nyilvántartás sem mondja, hogy a figyelmeztetés, a pontszám, a szabály és az ág ugyanahhoz a döntéshez tartozott. Mindenkinek van egy darabja a vázából. Az asztal még mindig vizes.

Amint az eseménykészlet meg van nevezve, a mérnökök szerződéseket tervezhetnek köré. Minden eseménynek lehetnek kötelező mezői. Minden mezőnek lehet gazdája. Minden sémaváltozás verziózható. Minden megőrzési szabály köthető jogi és működési igényhez. Ez nem a rendszer mellett heverő papírmunka. Ez a rendszer határának része. A nyilvántartás a munkafolyamat termékévé válik, nem pedig a munkafolyamat ebéd utáni bocsánatkérésévé.

Az idő nem díszítés

Az auditálás okkal megszállottja az időnek. Egy döntés, amely egy szabályváltozás előtt született, nem ugyanaz, mint amelyik utána. Egy modellkimenet, amely egy adatjavítás előtt készült, nem ugyanaz, mint amelyik utána. Egy ügy, amelyet határidő után emeltek szintre, különbözik attól, amelyet határidő előtt. Az idő nem metaadat, amelyet az eseményekre szórunk. Az idő az esemény jelentésének része.

Az elosztott rendszerek kínossá teszik az időt. Az órák elcsúsznak. A sorok átrendeződnek. Újrapróbálkozások történnek. A feldolgozók késve dolgozzák fel az üzeneteket. A kötegeket éjszaka töltik be olyan feladatok, amelyeket 2021-ben ideiglenesnek neveztek el, és amelyek mára kulturálisan állandóvá váltak. Ha az auditálási tervezés egyetlen rendezett idővonalat feltételez, az első incidens majd felvilágosítja. Ez a felvilágososodás általában egy táblázatkezelőben történik, ami drága tanterem.

Az auditálható tervezés megkülönbözteti az esemény idejét, a feldolgozás idejét, a hatálybalépés idejét és a felülvizsgálat idejét ott, ahol a különbség számít. Az esemény ideje azt mondja meg, hogy az üzleti folyamatban mikor történt a dolog. A feldolgozás ideje azt, hogy egy összetevő mikor kezelte. A hatálybalépés ideje azt, hogy egy szabály vagy állapot mikor vált érvényessé. A felülvizsgálat ideje azt, hogy valaki később mikor vizsgálta meg vagy javította. Ezek a megkülönböztetések aprólékosnak tűnhetnek, amíg egy ügy át nem lépi az éjfélt, egy szabály 09:00-kor meg nem változik, és egy sor lassan nem ürül, mert valaki magabiztosan, bizonyíték nélkül átméretezte a feldolgozói készletet.

Ugyanez a gondosság vonatkozik az azonosságra is. A szereplő lehet személy, szolgáltatás, ügynök, ütemezett feladat, delegált felhasználó vagy külső rendszer. A rendszernek meg kell mondania, hogy melyik. Nem bújhat a rendszergazda mögé, mert ott él az integrációs fiók. Amikor a jogosultságot delegálják, a delegálásnak láthatónak kell lennie. Amikor egy szolgáltatás automatikusan jár el, a tulajdonos szolgáltatásnak és szabálynak láthatónak kell lennie. Az auditálhatóság név szerinti felelősséget követel meg, még akkor is, ha a név nem emberi lény.

A rekonstrukció nem visszajátszás

Amikor a csapatok későn vezetik be az auditálhatóságot, gyakran megelégszenek a rekonstrukcióval. Összegyűjtik a naplókat, az adatbázis-pillanatképeket, a jegyeket, a csevegőüzeneteket és a kiadási jegyzeteket. Plauzibilis idővonalat építenek. Néha az idővonal helyes. Néha nagyon rendezett fikció, őszinte szerzőkkel. A probléma nem az, hogy az emberek hazudnak. A probléma az, hogy a rekonstrukció azt kéri az emberektől, hogy nyomás alatt töltsék ki a hézagokat, és az intézmények rendkívül jók abban, hogy a hézagok szándékosnak tűnjenek, amint egy vezetői megbeszélés elkezdődött.

Replay más mércét jelent. A replay azt jelenti, hogy a rendszer elegendő strukturált előzményt őrzött meg ahhoz, hogy a folyamat újra lejátszható legyen. Nem jelenti azt, hogy az eredeti modellt újra meg kell hívni, vagy hogy minden külső függőség feltámasztható. Azt jelenti, hogy a feljegyzés megmutatja, milyen bemenetet fogadott el a rendszer, melyik szabályverzió futott le, milyen kimenet született, milyen művelet történt, és milyen állapot lett az eredmény. A felülvizsgálónak képesnek kell lennie a lánc ellenőrzésére anélkül, hogy az aktuális alkalmazásra hagyatkozna, hogy hízelgő történetet meséljen saját korábbi önmagáról.

A replay megváltoztatja a mérnöki magatartást. Ha egy csapat tudja, hogy a döntéseket újra le lehet játszani, nehezebb lesz a szabályzatot olyan kódútvonalakba rejteni, amelyek neve például helper2. Nehezebb lesz a küszöbértékeket elcsúsztatni anélkül, hogy rögzítenék, ki módosította őket. Nehezebb lesz a promptsablonokat helyi kézműves tárgyként kezelni egy laptopon. A replay megköveteli, hogy minden jelentős művelet hordozza a saját kontextusát. Ez ugyanúgy bosszantó, mint ahogy a biztonsági öv is az: leginkább a baleset előtt.

A replay azt is lehetővé teszi, hogy az irányítás rutinszerűvé váljon. Ahelyett, hogy egy incidensre várnának, a csapatok mintákat vehetnek, láncokat vizsgálhatnak, összehasonlíthatják az eredményeket a szabályzatverziók között, és észlelhetik a hiányzó feljegyzéseket. Az auditnyom olyan dologgá válik, amelyet a szervezet használ, nem pedig olyanná, amelyet csak akkor állít elő, amikor sarokba szorítják. Ez a különbség számít. Azok az ellenőrzések, amelyeket csak félelem idején gyakorolnak, hajlamosak dísznek lenni.

A későbbi hozzáadás költsége

A késői auditálhatóságnak nagyon jellegzetes szaga van. Új táblák szaga, amelyek neve például audit_log_final. Egy adatexport szaga, amelynek megvan a legtöbb oszlopa, de nem azok, amelyek a kérdéshez kapcsolódnak. Egy tanácsadó szaga, aki megkérdezi, van-e egyetlen igazságforrás, és öt rendszer bemutatóját kapja. Mindenekelőtt a szándék visszafejtésének szaga a mellékhatásokból.

A közvetlen költség a mérnöki idő. A csapatoknak azonosítaniuk kell, hol történtek döntések, eseményrögzítést kell hozzáadniuk, visszamenőleg fel kell tölteniük a történeti feljegyzéseket, be kell foltozniuk a hiányosságokat, dokumentálniuk kell a feltételezéseket, és exportfelületeket kell építeniük. Ez a munka gyakran akkor érkezik, amikor a rendszer már felhasználókat, incidenseket, funkciókéréseket és elvárásokat hordoz. A közvetett költség rosszabb: a bizalom csökken. Ha a szervezet nem tud válaszolni az alapvető kérdésekre a saját rendszeréről, minden későbbi választ gyanakvással kezelnek, még a helyeseket is.

Van ennek egy tervezési költsége is. Ha egy rendszert eleve naplózhatóság nélkül építenek fel, a határai nem feltétlenül igazodnak a bizonyítékokkal szembeni elvárásokhoz. A döntés széteshet több összetevőre. Az állapot felülírásra kerülhet hozzáfűzés helyett. Az indokokat megjelenítésre számolhatják ki, de nem tárolják. A modell bemeneteit átalakíthatják, majd eldobhatják. Az emberi felülbírálatok megbújhatnak megjegyzésekben. Az utólagos naplózhatóság kiépítése ilyenkor kevésbé hasonlít egy ablak beépítésére, sokkal inkább annak felfedezésére, hogy a fal teherhordó.

A költség nem csak technikai. A későn bevezetett naplózhatóság politikai vitákat szül arról, hogy mi is történt valójában. Az emberek védik a csapatukat. A beszállítók védik az interfészeiket. A vezetők védik a bevezetési döntéseiket. Mindenki amatőr okságfilozófussá válik. Ez érthető, de többnyire haszontalan. Egy jó nyilvántartás csökkenti a személyiségvezérelt igazság iránti igényt. Lehetővé teszi az intézmény számára, hogy a politikáról és a fejlesztésről vitatkozzon, ahelyett, hogy arról vitatkozna, létezik-e a múlt.

A jó nyilvántartás nem megfigyelési színház

Jogos félelem, hogy a naplózhatóság megfigyeléssé válik. Egyes szervezetek, amikor azt hallják, hogy mindent rögzíteni kell, úgy viselkednek, mintha minden emberi tétovázás megérdemelne egy időbélyeget. Ez nem naplózhatóság. Ez intézményi szorongás, tárhellyel. A jó naplózási tervezés szelektív, arányos, és a lényeges változásokhoz kötött. A felhatalmazást és az állapotot rögzíti, nem a magánjellegű zajt.

A munkavállalók számára a különbség számít. Egy kezelő, aki jóváhagy egy kivételt, számíthat arra, hogy a jóváhagyást rögzítik. Nem számíthat arra, hogy minden kurzormozdulat egy állandó erkölcsi dráma részévé válik. Egy szakértő, aki felülbírál egy modellajánlást, hagyjon hátra egy indokkódot, és jelezze, ha a döntés egy ügyet érint. Nem büntethető azért, mert vitatkozik egy olyan automatizálással, amely eleve bizonytalan volt. A naplózhatóságnak láthatóvá kell tennie a szakmai ítélőképességet, nem pedig félénkké tennie a szakembereket.

A polgárok, ügyfelek, betegek vagy diákok számára a naplózhatóságnak a jogokat kell támogatnia. Lehetővé kell tennie egy döntés magyarázatát, a rossz adatok kijavítását, egy eredmény megóvását, a törlés bizonyítását, vagy annak megmutatását, hogy egy forrást nem használtak fel. Az a nyilvántartás, amely csak az intézményt védi, hiányos. A naplózási nyomvonal nem lehet egyirányú tükör. Ha a rendszer embereket érint, a nyilvántartásnak az ő jogos kérdéseikre is választ kell adnia.

Itt találkozik az adatminimalizálás és a naplózhatóság. A válasz nem az, hogy mindent örökre megtartunk. A válasz az, hogy a megfelelő tényeket a megfelelő ideig őrizzük meg, világos céllal, hozzáférési szabályokkal, valamint törlési vagy megőrzési logikával. Egy ritkás, jól strukturált nyilvántartás gyakran tiszteletteljesebb és hasznosabb, mint egy hatalmas halom rögzített kibocsátás. A halom biztonságosnak tűnik, amíg valaki meg nem kérdezi, mi van benne. Akkor kereshető kötelezettséggé válik.

A kockázati nyilvántartásnak kommunikálnia kell az eseménysémával

A kockázati nyilvántartások gyakran a kormányzási dokumentumokban élnek, míg az eseménysémák a mérnöki adattárakban. Ez a szétválasztás kényelmes és veszélyes. A kockázati nyilvántartás szerint fennáll a jogosulatlan jogosultságnövelés kockázata. Az eseménysémának ezért rögzítenie kell, hogy ki emelt szintet, milyen felhatalmazás alapján, melyik állapotból melyik állapotba, és hogy az emelés automatikus vagy manuális volt-e. Ha a séma nem rögzíti ezeket a tényeket, a kontroll csak áhított szándék. Az áhított szándék olcsóbb, mint a kontroll, ami megmagyarázza népszerűségét.

Ugyanez vonatkozik a modellkockázatra is. Ha a nyilvántartás szerint az alacsony megbízhatóságú ajánlásokat felül kell vizsgálni, a rendszernek rögzítenie kell a megbízhatóságot, a küszöbértéket, a felülvizsgálati követelményt, a felülvizsgálót, az eredményt és a kibocsátás vagy elutasítás indokát. Ha a nyilvántartás szerint a források köre számít, az eseményeknek rögzíteniük kell a források körét. Ha a megőrzés kockázatot jelent, az eseményeknek rögzíteniük kell a megőrzési állapot változásait. A kockázati nyilvántartás nem lehet a szoftver felett lebegő próza. Olyan állítások halmazának kell lennie, amelyeket a futási környezet segíthet ellenőrizni.

Ez nem azt jelenti, hogy minden irányítási követelmény azonnal kód lesz. Egyes kontrollok emberi, szerződéses vagy szervezeti jellegűek. De még az emberi kontrolloknak is szükségük van bizonyítékra. Egy kézi felülvizsgálat is létrehozhat nyilvántartást. Egy szerződéses kötelezettség is hozzárendelhető egy előírt igazoláshoz. Egy beszállítói folyamatot is képviselhet egy fogadott esemény, egy aláírt jelentés vagy egy hiányzó bizonyíték állapota. A lényeg az, hogy a kockázati nyelvet összekössük a bizonyíték nyelvével, mielőtt a rendszer következményeket kezdene termelni.

A csendes előny a jobb párbeszéd. A mérnökök nem úgy hallják többé az irányítást, mint egy késői szakaszban érkező feddést. Az irányítási csapatok sem úgy hallják a mérnöki munkát, mint a szélsőséges esetek fesztiválját. Mindkét fél ugyanarra az eseménysémára nézhet, és megkérdezheti, hogy hordozza-e a kockázat kezeléséhez szükséges tényeket. Ez kevésbé látványos, mint egy mesterséges intelligencia stratégiai műhely. De az esélye is kisebb, hogy egy olyan PDF szülessen, amelyet senki sem tud működésbe hozni.

A naplózhatóság megváltoztatja a fejlesztési beszélgetést

Amikor a naplózhatóság a kezdetektől jelen van, a tervezési felülvizsgálatok konkrétabbá válnak. A csapat nem csak azt kérdezi, hogy működik-e egy funkció. Azt is kérdezi, hogy milyen nyilvántartást hagy maga után a funkció. Azt kérdezi, hogy ki tekintheti meg a nyilvántartást, meddig él, mi javítható, mit soha nem szabad felülírni, és mely jövőbeli kérdésre kell tudnia válaszolni. Ezek a kérdések javítják a funkciót, mert felszínre hozzák a rejtett állapotot és a tisztázatlan felhatalmazást.

A beszerzés is megváltozik. Ahelyett, hogy a beszállítóktól kérdeznénk, támogatják-e a naplózást, amire szinte mindenki lelkes igennel tud válaszolni, a szervezet konkrét bizonyíték-képességeket kérhet. Exportálhatók-e a szabályzatverziók minden döntéssel együtt. Belefoglalhatók-e a modellazonosítók és a forráskörök. Megkülönböztethetők-e az emberi felülbírálások az automatizált műveletektől. Megtarthatók, törölhetők, aláírhatók vagy visszajátszhatók-e a nyilvántartások a mi szabályaink szerint. Megvizsgálhatjuk-e a nyomvonalat anélkül, hogy egy hősies professzionális szolgáltatási kalandért fizetnénk. Az utolsó pontnál szokott a terem oktató jellegűvé válni.

A működés is megváltozik. Az incidenskezelés kevésbé spekulatív lesz. Egy csapat azonosíthatja az érintett eseteket, összevetheti őket az ismert szabályzatverziókkal, megtalálhatja a hiányzó nyilvántartásokat, és megmutathatja a jelektől a cselekvésig vezető utat. A megfelelőségi munka kevésbé lesz szezonális. A termékfejlesztés őszintébbé válik, mert a csapat nem csak azt látja, hogy mit tett a rendszer, hanem azt is, hogy milyen feltételek mellett tette. A naplózhatóság nem fék a szállításon. Ez az egyik dolog, ami megakadályozza, hogy a szállítás jövőbeli feltárássá váljon.

Mindez nem teszi tökéletessé a rendszert. Egy ellenőrizhető rendszer még mindig hozhat rossz döntéseket. Még mindig kódolhat rossz szabályzatot, használhat gyenge adatokat, vagy működtethetik olyan emberek, akiknek nagyon is emberi napjuk van. Az ellenőrizhetőség nem garantál bölcsességet. Azt garantálja, hogy az intézménynek jobb esélye van arra, hogy lássa, mi történt, tanuljon belőle, és bizonyítsa, hogy nem csak utólag találta ki a választ.

A tanulság

A fő hiba az a feltételezés, hogy az ellenőrizhetőség a végére való, mert az ellenőrzések a végén történnek. Pedig nem így van. Az ellenőrzések a következmények után történnek, de az ellenőrizhetőségnek a következmények előtt kell léteznie. A nyilvántartásnak az aktussal együtt kell megszületnie. Az eseménynek magán kell hordoznia a kontextusát, amíg a kontextus még igaz. A rendszernek meg kell őriznie a különbséget tény, következtetés, szabályzat, felülbírálás és korrekció között.

Ez nem felhívás nehézkes folyamatokra minden apró eszköz körül. Ez felhívás az arányosságra. Minél inkább érint egy rendszer jogokat, hozzáférést, pénzt, biztonságot, jogosultságot, munkaterhelést vagy intézményi emlékezetet, annál inkább strukturált bizonyítékot kell hagynia. Kezdje a következményekkel járó határoknál. Nevezze meg az eseményeket. Verziózza a szabályokat. Őrizze meg az időt és az azonosságot. Tegye a korrekciókat additívvá. Tesztelje a visszajátszást, mielőtt a félelem belép a terembe.

Van valami szinte komikus ebben a fegyelemben. A megbízható automatizálás jövője kevésbé függ a látványos intelligenciától, mint attól, hogy emlékezzünk, melyik szabály lépett működésbe egy nyirkos februári szerdán. De a komoly intézmények ilyen emlékezetre épülnek. Nem azért bíznak a rendszerekben, mert a rendszerek magabiztosnak hangzanak. Azért bíznak bennük, mert a rendszerek ellenőrizhetők, amikor a magabiztosság már nem elég.

Tehát adja hozzá a bizonyítékot, amíg a munka még hétköznapi. A bemutató buli előtt, az incidens előtt, az átállás előtt, mielőtt a csapat elfelejti, miért volt opcionális az a mező. A később majd eljön. A később mindig eljön, hozva egy bizonyítékcsomag nevű mappát és egy kérdést, amely jobb választ érdemel, mint hogy valószínűleg.