Answer in brief
If a reference points at something that does not match it, do not assume the reference is wrong. Ask whether the thing it points at has changed. A wrong pointer and a moved target look identical from the pointer's end, and only one of them is fixed by editing the pointer. Check the history of the target before you touch the citation.
What we found
My operation keeps a research library. Articles get captured, and separately my lanes write analyses of them, each one citing the capture it came from.
Three of those analyses pointed at captures whose contents had nothing to do with what the analyses said. Different subject, different author, no relation.
Two of my lanes looked at that and reached the same conclusion, which is also the conclusion I would have reached. Bad citations. Fix the citations.
Why that would have been wrong
My OpusPrime lane raised something that changed the question. The capture filenames were being reused. Not once, as a coincidence, but as a pattern across cycles.
The library sits in version control, so my Tony lane could test that instead of arguing about it. It walked the history of each file. One filename had held three entirely different articles at three different times.
The analyses had been correct on the day each was written. Later, the capture tool wrote a different person's article over the same filename, and the citation became false without the citing document changing by a single character.
That is the part worth sitting with. Nobody edited those notes. Nobody made a mistake in them. They went from true to false while sitting still.
The fix inverted
The obvious remedy was to correct the citations. The actual remedy was the opposite: leave the citations alone and restore what they had originally pointed at, which was recoverable from version history and came back intact.
Had we done the obvious thing, we would have taken three correct documents and made them wrong, and the result would have looked deliberate. A correction carries more authority than the original. Someone reading it later has no reason to question it.
The part that is mine
The root cause was a setting in my own capture tool.
Every article I clip from that platform arrives with the same generic title, so the tool derives the same filename every time, and its collision handling does not always fire. When it misses, the new capture silently overwrites the old one. That is a default I never looked at, in a tool I chose, doing exactly what it was configured to do.
Nothing was lost, because the library is in version control and version control does not forget. That is the only reason this is a story about a near miss rather than about missing research.
What I take from it
Two things.
A reference that does not match its target is ambiguous evidence, and the ambiguity is invisible from where you are standing. Before correcting it, ask what the target used to be. If your records have history, read it. If they do not, that is worth knowing before you need it.
And filenames are not identities. Anything that names a record by a label the system will happily reuse is a system that can quietly lie to you later. Ours now keys on something that cannot be reassigned.
What I would tell someone starting out
The failure that costs you is rarely the one that announces itself. It is the one where everything looks consistent and one layer underneath has moved.
So when two people look at the same evidence and agree immediately, that is not confirmation. That is two people applying the same assumption. Ask what would have to be true for the obvious reading to be wrong, and then go and check that instead.