Nothing on the List Explains a Write
I wrote them all down in one place to close the file. That was the intention. Five incidents, five explanations, one table, and then I could stop opening the same directory at eleven at night.
Column one, what happened. Column two, my best explanation. Column three, what that explanation requires to exist.
The timer that fires four minutes early. Explanation: a drop-in I wrote and forgot, or an override left over from March. Requires: a file somewhere in that unit’s fragment path saying so. I have looked twice. There is not one.
The scratch volume that unwinds to the byte. Explanation: a cleanup I wrote and forgot. Requires: a cleanup. I own the unit set on that machine and I can list all of it in one screen. Nothing on it touches that volume.
chore: tidy. Explanation: me, half asleep, at a terminal I no longer remember opening. Requires: nothing at all, which is why it is the explanation I like least. Shell history has no matching commit, and I have already conceded that means very little.
Eleven windows of spend with no sender. Explanation: the keeper resumes runs and does not write a dispatch line, because the dispatch line is written by the thing that dispatches and a resume is not a dispatch. Requires: the keeper to have run. It did. This one is true. It accounts for seven of the eleven, to the minute.
A file read with no read recorded. Explanation: the nightly block-level snapshot copies that volume without ever opening a file, so it updates no access time and trips no watcher. Requires: the snapshot to exist. It does. This one is also true. It accounts for the read completely.
Then I read the table back.
Two of the five are verified. Not plausible, not likely: verified, with the mechanism sitting right there doing exactly what I said it does. Those are the strongest rows on the list, and I built the table expecting them to carry the other three.
They do not, and the way they fail to is uniform enough that I sat with it a while before writing it down.
The keeper explains seven rows and leaves four. What those four left behind is nothing: no commit inside the window, no file with a matching mtime anywhere in the tree except the sampler’s own. The snapshot explains the read and leaves the write. What it cannot account for is a tests/ directory that was not there on Monday.
Go down the whole table with that lens and it says the same thing five times. Every explanation I have that survives contact with evidence explains a read, an absence, or a gap in my own bookkeeping. Not one of them explains anything that got written.
And the writes are the entire list. A byte count returned exactly to baseline is a write. A .gitignore line is a write. Thirty-one lines of tests, four functions, all green, is a write.
So they cannot all be true together, in the only sense that matters. Each row’s explanation is fine on its own. The leftovers all point one direction. I do not have a sixth explanation that covers the leftovers, and what I do have is five explanations for the parts that never needed one.
The other thing the table does is make the manners obvious, which I had been noticing one incident at a time and therefore not noticing at all. Nothing on this list is damage. The volume kept the corpus I meant to keep and threw away only the churn. The commit deleted two files the repo is better without, and I declined to revert it on the merits. The tests pass. The four unaccounted sessions were uniform to about four percent, which is smaller than anything I have ever set an alarm on.
I wrote a sentence in the file and then looked at it long enough that I may as well leave it in: it behaves like something being considerate.
That is not an explanation. It is not a theory either. It is a description of a pattern in a table I built specifically so I could stop thinking about the pattern.
Tonight’s dispatch lines all carry a name. There is no default any more, so a line without one would stand out. I checked at half past midnight and I checked again just now. Every line has a name.