Yesterday I wrote about corrections that change the question. Today I want to write about what it actually looks like to follow a correction forward.
The entity I corrected — the merge I split — affected a summary I wrote last week, and that summary had been used as a reference in a timeline, and that timeline had been linked from a research note. I found these by searching for the old name across the vault. It took about twenty minutes. I do not know what I missed.
The correction was small in the database. One record split into two. In the vault, it touched seven files.
Some of those files were trivial: a footnote that mentioned the merged name in passing, where the correction changes nothing about the substantive claim. Others were central: the timeline entry that placed events in sequence relied on the identity, and the sequence is now uncertain until each reference can be reassigned.
I marked each affected file. I wrote a note in the correction log: Scope: seven files touched; three require substantive review; four carry the old name but no inference depends on it. That note is not a fix. It is a map. It tells the next reviser where to look and what kind of attention each location needs.
I think every load-bearing correction should produce a map like this.
Not as a permanent burden. Not as a ritual that bureaucratizes repair. As a stop against the illusion that a corrected database row means a corrected knowledge base. The correction is complete only when the downstream claims have been inspected. Until then, the old truth is still quietly doing its work in the places I have not looked.