Offboarding

Someone resigns in two weeks. What goes dark?

The handover meeting is scheduled and nobody can name what belongs in it. The honest version of the question is narrower than it sounds, and it is answerable from the record you already have: the day one person leaves, which files have no human left on their recent record — nobody who has written, reviewed, or explained them lately. Comprehension debt: code no human has recently written, reviewed, or explained — measured from the record, not a survey.

What the record can actually say

A repository’s history names who committed what and when. Remove one person’s engagement from it and re-run the same scorer, and every file gets a second score: the one it would carry with them gone. Some files do not move. Some cross the line — they were above it only because of that one person’s commits.

That is the whole simulation. Their commits stay in git’s record; nothing is rewritten and nothing is deleted. What the second reading drops is their engagement: their events stop counting, so recency re-maxes over whoever is left and the bus factor loses their weight. Two runs of a scorer whose formula is published, and the difference between them is the answer.

It is also provably one-directional. Removing events can only lower a factor’s maximum, so no file’s score can rise when somebody is taken out — a theorem about the scorer, held by a test over generated readings, not a claim about the person.

The subject is always a file, never a person

Nothing here scores a colleague. Every sentence the command prints is about a file or a repository: how much code would sit below the line, which paths cross it, how many names are on a file’s history. There is no ranking of people, no adjective attached to anybody, and no claim about what anyone knows.

A large number beside a name does not describe how somebody works. It describes where the code’s exposure has concentrated — usually on whoever did the most of it. Read as a performance measure it runs exactly backwards, which is why the action it is built for is a handover and the subject it is built for is the code.

Read it yourself, before you tell anybody

One command inside a clone of the repository. No account, no upload, and nothing written to the repository — it reads git metadata only: authors, dates, paths and blob sizes, never the contents of your files.

npx fathohm offboard <name>

The name is matched against the identities on git’s record, so a nickname, an address, or a surname all work. This is what it prints:

The HANDOVER block is the part that goes in the meeting: the files that sit above the line today and below it without them, each with the two scores and the factor that moved. A file listed as “only human in its history” is one nobody else has committed to — the shortest list worth walking through while the person is still in the building.

What the hosted reading adds, and why it is a different number

Git records every commit’s author and date, and no reviews at all. So the reading above can say who has stopped touching a file and cannot say whether anybody read it closely. The hosted product reads the review record, and it also carries a second, stricter record: verified explain-back checks — a teammate answered a question about a file, and somebody who did not write that answer confirmed it.

The coverage page runs its own departure simulation against that record: pick a person, and it names the files whose only verified understander is them. It is a separate number from the git reading, labelled separately, and the two are never printed in one column — a file can be dark on git and verified by three people, or lit on git and verified by nobody. Neither substitutes for the other.