A key system author is leaving.
Departure
The engineer who built our settlement system has given four weeks' notice. Nobody else knows how it works, and whatever they know has to be in writing before they go.
The CIO
What knowledge needs to remain when the author leaves?
The product at work
The system drawn from its code: what it reads, what it writes, what leans on it.
What the system holds up, marked: the daily report, the management report, the month-end total.
The documentation opens at one step: what it does, what it reads and writes.
The author's answers, in the Finding register, attached before they go: confirmed, corrected, still open.
What usually happens
The handover is a run of meetings and a document written from memory, which is good on what they remember and silent on what they never thought to say. Six months on, the first question arrives and the document has no answer.
With a reading
With a reading, the system is documented from its code, line by line, and the author's answers sit beside it before they go, recording what they confirm, what they correct and what nobody can settle yet.
Source-linked documentation of the relationships in scope, with the author's answers, unresolved questions and disagreements retained.
The documentation follows the code, with the author's answers beside it. Checking it, running the system and owning it stay with the team after the author has gone.
Who it is for
For the CIO, head of engineering or service owner with four weeks to make one person's knowledge the system's own, captured in the CGS Docs.
What to bring
The code, configuration and schedules of the system, and time with its author before they go.