The Citation That Dies

"A citation you can't return to isn't a citation. It's a rumor with a footnote."

What a Citation Actually Promises

When you cite something, you make a promise to your future self and to everyone who trusts you: go here, and you will find these exact words. The whole value of a citation is that the promise holds — next week, next year, after the database is rebuilt, after you switch machines. A citation is only as good as its stability under change. If the thing it points at can move without the citation knowing, the promise is already broken; it just hasn't been caught yet.

The Fragile Defaults Everyone Reaches For

Three reflexive ways to reference a result all die on contact with reality:

Position: "the 3rd search result." Re-run the query, or re-index the corpus, and the 3rd result is now something else.
Row id: the auto-increment integer the database assigned at insert time. Purge and rebuild the index and every row gets a fresh number — your saved id=417 now points at an unrelated chunk, or nothing.
Offset alone: "characters 4120–4229 of the document." Fine until the document is edited above that point and every offset shifts.

Each feels stable because it works today. Each is a time bomb wired to the next rebuild.

Re-index Is Not a Rare Event

Here's what makes this urgent rather than theoretical: in a living corpus, re-indexing happens constantly. Every edit, every new document, every profile tweak triggers a rebuild of some slice of the index. If your citations are position-bound or row-id-bound, they aren't decaying slowly — they're being invalidated every single day, and you won't notice until you follow one and land on the wrong paragraph.

Anchor references to content, not to position or insertion order. Anything that depends on where something sits (which row, which position, which offset in a mutable document) will break when the thing moves. Anything derived from what the content is survives every reshuffle. Durable references are content-addressed by construction — the address is computed from the thing itself.

The Fix, Previewed

The next lesson builds the answer: a chunk id computed by hashing the content and its coordinates together, so the id is a fingerprint of the text rather than a label stuck on a shelf. Rebuild the index, move to a new machine, purge everything and re-ingest — the fingerprint comes out identical, and every citation that used it still lands exactly where it promised. Content-addressing turns a citation from a rumor into a guarantee.

Code

Row-id citations rot on rebuild; content-addressed ones don't·python

# FRAGILE: cite by the row id the database happened to assign.
citation = {"chunk_row_id": 417}
# Tomorrow you purge and rebuild the index (routine!). Rows get renumbered.
rebuild_index()
fetch(citation["chunk_row_id"])   # -> a DIFFERENT chunk, or a KeyError. Silent rot.

# DURABLE: cite by a fingerprint of the content itself.
citation = {"chunk_id": "9f3ce1a7b2..."}   # hash of content + coordinates + profile
rebuild_index()                             # same sources, same profile...
fetch(citation["chunk_id"])   # -> the SAME chunk. The fingerprint didn't change.

Exercise

Find a reference you've saved that points at a position rather than content — a bookmark to 'page 2 of results', a note that says 'the 4th item in that list', a link to a document section by number. Ask what happens to it when the underlying thing is reordered or rebuilt. Then redesign the reference to be anchored to the content itself. What would you hash or copy so it survives the reshuffle?

Hint

The move is to capture something intrinsic to the content — a hash of its text, or the exact words themselves — instead of its coordinates. If the reference can be recomputed from the content, it can never be orphaned by a reindex.

What a Citation Actually Promises

The Fragile Defaults Everyone Reaches For

Re-index Is Not a Rare Event

The Fix, Previewed

Code

External links

Exercise

Progress

Comments 0