Papiret må ikke se færdigt ud

Der ligger et færdigt arbejdspapir på hvert punkt i tjeklisten, før revisoren overhovedet åbner punktet. Det er den del, der er nem at fortælle om.

Reglerne for, hvad det papir har lov til, er den del, jeg synes er mere interessant.

Det henter det samme som skærmen

Arbejdspapiret hentes med præcis de samme funktioner og de samme parametre som det panel, revisoren ser på skærmen.

Det lyder som en implementationsdetalje og er samtidig den beslutning, alt det andet hviler på. Havde papiret sin egen forespørgsel mod databasen, ville der findes to sandheder om det samme punkt, og de ville drive fra hinanden i det øjeblik, nogen rettede den ene. Så ville revisoren sidde med et skærmbillede, der siger ét, og et dokument, der siger noget andet, og der er ingen god måde at opdage det på.

Med én kodesti kan de to ikke være uenige. Papiret er en anden præsentation af det samme opslag, og hvis skærmen tager fejl, tager papiret fejl på nøjagtig samme måde. Det er en langt bedre tilstand end den, hvor de fejler hver for sig.

Det skriver aldrig noget selv

Papiret formulerer ingenting. Det gengiver, hvad der er hentet, og det tilføjer ikke en vurdering, en formulering eller en konklusion, som ingen har taget stilling til.

Det er en meget snæver regel, og jeg holder den, fordi papiret ender med at blive dokumentationen bag et regnskab, som et menneske skriver under på. I det øjeblik en model må formulere en konklusion i det dokument, har jeg lagt en sætning i munden på en person, der bagefter hæfter for den. Det vil jeg ikke bygge, uanset hvor godt modellen skriver.

Det afbryder frem for at gætte

Og så er der den regel, jeg synes flest bør overveje i deres eget arbejde.

Mangler der data, eller kan grundlaget ikke hentes, afbryder papiret med en begrundelse. Der bliver ikke afleveret et dokument med et hul, en tom rubrik eller en pæn formulering, der dækker over, at noget ikke kunne hentes.

Grunden er formen. Et arbejdspapir er et dokument, der ser autoritativt ud i kraft af at være et dokument. Overskrifter, afsnit, tal, dato. Man læser det som et papir, og et papir ser altid færdigt ud. Så et hul i et papir bliver læst som "her var der ikke noget", når det i virkeligheden betyder "her kunne systemet ikke hente noget".

De to ting er meget forskellige for den, der skriver under, og de er umulige at kende fra hinanden bagefter.

Derfor er "jeg kunne ikke" et førsteklasses resultat i det her system. Det har sin egen visning, sin egen begrundelse og sin egen plads i flowet. Det er et resultat på lige fod med et udfyldt papir, og det er den slags, jeg tror alt for få bygger, fordi det ser ud som en fejl i en demo.

Det gælder bredere end tjeklister

Det her er den ene regel, jeg ville tage med mig til hvilket som helst andet AI-projekt.

Modeller er trænet til at aflevere noget. De er gode til det, og de bliver ikke i tvivl på en måde, der er synlig i outputtet. Så når du sætter en model til at producere et dokument, får du et dokument. Spørgsmålet er kun, om det, der står i det, kom fra data eller fra formen.

Det er i praksis umuligt at se udefra, og derfor skal afbrydelsen ligge i systemet omkring modellen. Nogen skal have besluttet på forhånd, hvilke data der skal være til stede, før dokumentet overhovedet må dannes, og hvad der sker, når de ikke er der.

Når et punkt bliver markeret færdigt, fryser papiret, og et frosset papir ændrer sig aldrig igen. Bliver punktet åbnet igen, genoptager det vedligeholdelsen. Det er den samme tankegang: dokumentet skal svare til en bestemt tilstand på et bestemt tidspunkt, og det skal aldrig kunne komme til at se ud, som om det gør noget andet.