The AI Learning Hub Journal

The Workpaper Question

What goes in the file when a tool did the readingnot a new documentation philosophy — the ordinary discipline of the workpaper, applied to a new kind of preparerTHE FOUR QUESTIONS THE FILE ANSWERSWHAT WENT INwhich documents, whichpopulation, which version —and what was excludedWHAT CAME OUTthe output actually relied on,kept as produced ratherthan as rememberedWHAT THE AUDITOR DIDthe follow-up performed, thepointers opened, exceptionsresolved or escalatedWHY RELIANCE WAS REASONABLEwhat the team knew of the tool,the checking of its work, thethinking output-to-conclusioncapture at the time — the tool will not remember for you, and neither input nor output is reconstructable afterwardsTHE TEST — AN INSPECTOR, THREE YEARS ON, WITHOUT THE TOOL IN THE ROOMthis year: the reviewersees the work, challenges itmeanwhile: the tool is updated,replaced or retiredthree years on: the file alone must explainwhat the tool did, what went in and came out,and why the team relied on itif the answer requires a live demonstration of software that no longer exists in that form, the file does not support the relianceaudit files are precisely the documents read years later by people whose professional duty is scepticism about youA SCREENSHOT IS NOT AN EXPLANATIONit records what the software displayedat one moment — not what was loaded, whatsettings shaped the run, what went unflagged,or why any of it justified reliancethe form of documentation without the content —it answers none of the four questionsTHE BETTER HABIT — IT COSTS LITTLE MOREexport the inputs andoutputs where thetool allows itnote the configurationand the date ofthe runwrite the short paragraphof reasoning a revieweractually needsfluent form standing in for absent content is this course’srecurring warning, here in miniatureA PARAGRAPH OF HONEST REASONING OUTLIVES ANY INTERFACEwhat went in, what came out, what the auditor did, and why reliance was reasonable — captured at the time
Write for the inspector reading the file cold, years on, without the tool in the room — the reader the file was always for.

What Went In, What Came Out

When a tool did the reading, the file answers four questions. What went in: which documents, which population, which version of it, and what was excluded. What came out: the output actually relied on, kept as produced rather than as remembered. What the auditor did about it: the follow-up performed, the pointers opened, the exceptions resolved or escalated. And why reliance was reasonable: what the team knew about the tool, the checking performed on its work, and the thinking that connected its output to the conclusion drawn. None of this is a new documentation philosophy — it is the ordinary discipline of the workpaper applied to a new kind of preparer. The uncomfortable part is only that the tool will not remember for you: what went in and what came out must be captured at the time, because neither can be counted on to be reconstructable afterwards.

  • What went in: documents, population, version, and what was excluded
  • What came out: the output relied on, kept as produced rather than as remembered
  • What the auditor did, and why reliance was reasonable, connect output to conclusion
  • Capture at the time — inputs and outputs are rarely reconstructable afterwards

The Reviewer, and the Inspector Three Years On

The test for whether the documentation is enough has two audiences. The first is the reviewer this year, who must be able to see what was done and challenge it. The second is harder: an inspector three years from now, reading the file cold, with the tool by then updated, replaced or retired. Could someone explain, from the file alone and without the tool in the room, what the tool did, what went in, what came out, and why the team relied on it? If the answer requires a live demonstration of software that no longer exists in that form, the file does not support the reliance — and audit files are precisely the documents that get read years later by people whose professional duty is scepticism about you. Write for that reader. They are the one the file was always for.

  • Two readers: the reviewer this year, and an inspector years later reading cold
  • The test: explain the reliance from the file alone, without the tool in the room
  • Tools update, get replaced and retire; the file must not depend on a live demonstration
  • Audit files are read years later by people whose duty is scepticism about you

A Screenshot Is Not an Explanation

The most common documentation instinct is also the weakest: capture an image of the results screen and file it. A screenshot records what the software displayed at one moment. It does not record what was loaded, what settings shaped the run, what the tool failed to flag, what the team did with the flags, or why any of it justified reliance — which is to say, it records none of the four questions. It has the form of documentation without the content, and fluent form standing in for absent content is this course's recurring warning in miniature. The better habit costs little more: export the inputs and outputs where the tool allows it, note the configuration and the date, and write the short paragraph of reasoning a reviewer actually needs. A paragraph of honest reasoning outlives any interface.

  • A screenshot records what was displayed — none of the four questions the file must answer
  • Form without content is this course's recurring warning, here in miniature
  • Export inputs and outputs where possible; note configuration and date
  • The short paragraph of honest reasoning outlives any interface

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.