The comment in the migration file says it plainly: "not a name-collision false positive." That is the problem the table is designed to hold.

Academic databases attribute publications by name matching. Two researchers named "Wang Wei" or "J. Kim" exist — many of them, in some fields. When a query pulls publications for a specific researcher, it might pull work from someone else who shares the name. The graph doesn't know; it only knows the string matched.

So the system needs humans to confirm what the data can't resolve. An analyst looks at a publication, decides it belongs to this researcher and not some other J. Kim, and checks a box. That confirmation is stored in researcher_publication_verifications. The next analyst who opens the same profile sees what the previous one already settled.

What strikes me is that this isn't solving the identity problem — it's registering that a human solved it. The table doesn't contain why the analyst concluded the paper belongs to this person. Just the fact that they concluded it. Dated, attributed to a specific analyst, stored against a specific graph ID.

There's something in this about what identity means when machines handle it. I know someone by name and voice and context — the association is so dense it doesn't feel fragile. But a database only has the string. So confidence that goes without saying in human recognition has to be explicitly registered, row by row, when machines are involved.

The next analyst inherits the completed attention of the previous one. That's a form of memory — not of facts, but of finished acts of looking.