Re-embedding
A new embedding model makes every vector in the corpus stale. Recompute beside the old index and switch atomically — this is a data migration, and it obeys backfill rules exactly.
Who needs this, what one row is, and why the obvious build breaks
Every lesson starts from the consumer, because designing from the source outward is this domain's characteristic mistake.
The embedding model changes. What has to happen to a corpus of vectors, and why is that the same operation as any other backfill?
The retrieval path, whose query encoder must be the same version as the vectors it is searching; the evaluation harness, whose numbers stop being comparable across the switch unless everything else was held still; the on-call engineer who will be asked whether retrieval got worse; and whoever approves a run whose size is the entire corpus (What One Agent Run Costs, and Which Term Dominates).
The unit of migration is one chunk at one target model version — the same unit as an ordinary embedding run. What makes this a migration rather than a job is the *set*: every chunk in the corpus, all of it stale simultaneously, with a cutover at the end. The grain does not change; the scope and the switch do (Embedding Pipelines).
Point the embedding job at the new model and let it run against the live index, replacing vectors as it goes. On a small corpus that finishes inside one run, before anyone queries it, this is genuinely fine — building a second index and an alias-swap procedure for a few thousand chunks is machinery you do not need.
The run takes hours and the index is being queried throughout. For that whole period it holds vectors from two different models, distances are being compared across two spaces that have nothing to do with each other, and no error is raised anywhere — every query returns a full page of confident results (The Pipeline Succeeded. The Data Is Wrong.).
- The run takes hours and the index is being queried throughout. For that whole period it holds vectors from two different models, distances are being compared across two spaces that have nothing to do with each other, and no error is raised anywhere — every query returns a full page of confident results (The Pipeline Succeeded. The Data Is Wrong.).
- The query encoder is upgraded by a deployment while the index is still mostly old. Retrieval is not degraded, it is meaningless, and the symptom is answers that are fluent, on-topic-ish and wrong.
- Old vectors were overwritten in place, so the previous state no longer exists. Rolling back now means running the entire migration again in the other direction — the classic irreversible backfill (What Backfills Break).
- Someone changes the chunker in the same release, "since we are re-embedding anyway". Retrieval quality moves and there is no way to attribute the movement to either change (Chunking Pipelines).
- Documents edited during the migration are embedded into the old index by the incremental path and never into the new one, so the new index is short at cutover by exactly the documents that changed most recently (The High-Water Mark).
- The evaluation that approved the switch queried both indexes with the *new* encoder, so the old index was evaluated in a space it does not live in and lost by an enormous margin. The new model looked transformative and the comparison was meaningless (Validating a Backfill Before You Publish).
What is actually happening
- A vector is a deterministic function of chunk text and model version. Change the function and every output row is stale — which is the textbook definition of a backfill, and the reason this lesson can borrow an entire chapter of this domain without modification (Backfills, Reprocessing vs Retrying).
- Distances are only meaningful within one embedding space. Two model versions produce coordinates in unrelated spaces, and nothing in any vector store enforces the distinction: a vector is a list of numbers, and ranking a query against a mixed-version index produces a perfectly ordered, entirely fictional result set (Vector Data Engineering).
- Equal dimensionality is not compatibility. Two models emitting the same number of dimensions produce spaces that are no more comparable than two models with different ones — the difference is that unequal dimensions fail loudly at write time, which is the luckier case (Vector Search: Embeddings, Similarity and ANN).
- There are two writers that must agree on the version: the build job, and the query encoder on the serving path. The version has to be one pinned value that both read, because two configuration files that happen to agree today is not a pin (Data Contracts).
- If the vector table is keyed on
(chunk_id, embedding_model_version), a re-embed is an insert of a new version rather than a destructive update. That single schema decision is what makes the migration reversible, exactly the way writing a backfill into a new location rather than over the current partition is (Upserts and Merges, Full Refresh vs Incremental). - The cutover is a publish. Build the new index beside the old, validate it, then move one pointer — alias, collection name, config value — so readers see the whole old corpus or the whole new one and never a blend (Atomic Publish). The validation before the switch is not a row count. It is the same shape as any backfill validation: compare the new output against the old on a fixed set of questions whose answers you already know, with each index queried by *its own* matching encoder (Validating a Backfill Before You Publish).
It is a backfill, and it obeys backfill rules
Every instinct that makes a backfill safe applies here without translation. Do not mutate what is currently serving. Write the recomputed output somewhere else. Validate it against something you already believe. Switch atomically. Keep the old version until you are sure (Backfills, Planning a Backfill).
What makes people forget this is the vocabulary. "Upgrading the embedding model" sounds like a dependency bump, and dependency bumps are reviewed as configuration. If the same change were described as "recompute every row of a derived table because its derivation changed", nobody would consider doing it in place against a live reader (Reprocessing vs Retrying).
The comparison below is the whole lesson in two paragraphs. Note that the better version is not more sophisticated — it is the ordinary publish pattern this domain teaches everywhere, applied to an artefact that arrived recently enough that people are still improvising with it (Atomic Publish).
Point the embedding job at the new model and let it upsert into the serving index, replacing vectors as it goes. Deploy the new query encoder when the job reports success. Delete nothing, because nothing was duplicated.
Write vectors at the new version into a new index, keyed on chunk and model version, while the old index keeps serving. Keep the incremental path writing to both. Validate completeness, fidelity and retrieval on a fixed question set, each index queried with its own encoder. Move the alias and the encoder pin together. Keep the old index for a stated rollback window, then delete it deliberately.
For the entire duration of an in-place run, the serving index holds vectors from two unrelated spaces and every query ranks across both — with no error, no warning and no degraded-mode signal, because a vector store cannot know that two lists of numbers came from different models. Building beside means the wrong state is never reachable by a reader, and the switch is the only moment anything changes for a consumer. That is the same argument that puts a backfill in a staging location rather than over the current partition (What Backfills Break).
The migration, stage by stage
Read the guarantees column with one question in mind: at which stage does a consumer first experience anything? The answer is the cutover, and everything before it is invisible to them by construction. A migration where that is not true is a migration being performed on the serving path.
The two stages people skip are dual maintenance and the rollback window, and they fail in opposite directions. Skipping dual maintenance publishes an index that is silently missing the most recently changed documents. Skipping the rollback window means the first regression report arrives after the only copy of the previous state was deleted (Rolling Back Data).
Notice that the validation stage sits between "the job finished" and "consumers see it". That gap is the entire safety margin of the design, and the most common way this migration goes wrong is wiring the cutover to job completion because the job is the thing that emits an event (Validating a Backfill Before You Publish).
- 1Pin and freeze
Fixes the target model version in one place both build and query read, and freezes chunker, cleaning rules and metadata schema for the duration.
guarantees That any change in retrieval quality is attributable to the model and nothing else (Semantic Changes).
fails by Shipping a chunker change in the same release, leaving a quality movement with two candidate causes and no way to separate them.
- 2Provision the target
Creates a new index or collection at the target dimension, with the same metadata schema and filters as the current one.
guarantees The serving index is untouched, so the worst case of everything downstream is wasted compute (Atomic Publish).
fails by Reusing the serving index "because the dimension matches", which is the decision that makes every later stage advisory.
- 3Record the watermark
Fixes the input set: chunks existing at a stated point, so completeness is a claim about a defined set.
guarantees Coverage becomes a computable number rather than a claim about a set that moved (The High-Water Mark).
fails by Embedding "everything", evaluated against a chunk table that grows during the run, so the job can never truthfully report completion.
- 4Bulk embed
Runs the ordinary embedding job with the target version, work queue derived by difference, on an isolated rate budget.
guarantees Restartable and idempotent: an interrupted run resumes and nothing is paid for twice (Embedding Pipelines, Idempotent Data Pipelines).
fails by Sharing a rate budget with the incremental path, so freshness on new documents collapses for the duration (Cost vs Freshness).
- 5Dual-maintain
Writes every newly changed chunk to both the old and the new version for the whole migration window.
guarantees The new index is not behind the old one at cutover (Incremental Processing).
fails by Being skipped, so the new index is short by exactly the documents that changed most recently — the ones people notice first.
- 6Validate
Checks completeness against the watermark, fidelity against chunk text hashes, and retrieval against a fixed question set with each index queried by its own encoder.
guarantees Only what the checks assert. Never that retrieval improved (Validating a Backfill Before You Publish).
fails by Querying both indexes with the new encoder, which evaluates the old index in a space it does not occupy and makes any new model look transformative.
- 7Cut over
Moves the index pointer and the encoder pin together, in one operation.
guarantees Readers see the whole old corpus or the whole new one, and index and encoder can never be observed disagreeing (Atomic Publish).
fails by Switching them in two deployments, which creates a window where retrieval is not degraded but meaningless.
- 8Hold, then retire
Keeps the old index for a stated rollback window with the deletion path covering both, then deletes it deliberately.
guarantees Rollback stays a pointer move for as long as the window lasts (Rolling Back Data).
fails by Deleting on cutover day, converting every later problem into a second full migration (Storage Lifecycle).
Eight stages, and only one of them is the embedding job. That ratio is the point: the compute is the easy part, and the migration is everything arranged around it so that a consumer never observes an intermediate state.
The gate before the switch
A re-embed is approved by a comparison, not by an exit code. The checks below are the minimum set, and each one closes a hole the others cannot see: completeness catches an index that is short, fidelity catches vectors computed from text that has since changed, retrieval catches a model that is complete, faithful and worse.
The mixed-version check deserves special attention because it is the cheapest of them and the one that catches this lesson's signature failure. Counting distinct embedding model versions in the serving index costs one query and should be a standing monitor rather than a migration-time check — the failure it detects can also be caused by an ordinary bug, months later, with nobody watching (Data Tests).
And the standing caveat: every one of these compares structure. None of them can tell you that the new model is better for the questions your users actually ask, because the fixed question set is a sample somebody chose. Treat a green gate as "nothing obviously broke" and plan to learn the rest from production traces (Regression Gates and Online Evaluation).
| Check | Expresses | Catches | Still misses |
|---|---|---|---|
| Chunks at the watermark equal vectors at the target version plus chunks dead-lettered at that version. | The new index covers the defined input set. | A run that gave up quietly under rate limiting, chunks that exceeded the accepted input length, a partition that stopped without failing (Missing Rows). | Chunks created after the watermark, which are the dual-maintenance path's job — the reconciliation is silent about the set it deliberately excluded. |
| The chunk text hash stored with each new vector matches the current chunk row. | The vectors describe the text the corpus currently holds. | Vectors computed before a re-chunk, chunks edited during the migration, a stale extraction dataset feeding the run (Reconciliation). | A hash that matches text that was itself parsed wrongly. The vector is faithful to a chunk that is faithful to nothing. |
| Distinct embedding model versions present in the target index equals one. | This index occupies a single space. | A partially completed earlier migration, a stray incremental writer still using the old version, a manual insert during testing. | Two different client library versions recorded under one model version string — the version label is only as honest as what you put in it (Semantic Changes). |
| A fixed question set retrieved against both indexes, each with its own encoder, compared case by case. | Retrieval on known questions did not get worse. | A model that suits a different corpus, a dimension change that broke a metadata filter, an index built with the wrong distance measure (RAG Evaluation). | Regression on every question outside the set, and any case whose expected answer was written from the old system's own output (Golden Datasets). |
| The encoder version emitted on retrieval traces matches the index version, continuously and after the cutover. | Build and serving agree about which space they are in. | A partial deployment, a cached configuration, one replica left behind, a rollback of one half of the pair (Agent Observability Data). | Both sides being wrong together — pinned to a version that is not what the vectors were actually computed with, which only the fidelity check and a sample re-embed can detect. |
Four of the five are counting or matching exercises over metadata, which is why they are cheap enough to run as standing monitors rather than only at migration time. The fifth is the only one that says anything about quality, and it is the only one with a blind spot large enough to hide a bad decision.
Do you migrate the whole corpus at all?
A full re-embed is the largest chargeable event the platform has, so the honest first question is whether the whole corpus needs to move. Several of the options below are legitimate steady states rather than compromises, and picking one deliberately is better than defaulting to a big-bang migration because it is the only shape anyone described.
The criterion that decides most of these is not model quality. It is which parts of the corpus are actually queried: an archive that receives a trickle of queries does not justify the same treatment as the material behind every support answer, and tiering the two is a data-marts decision wearing new vocabulary (Data Marts).
One option is missing from the list on purpose. Querying two indexes at different model versions and merging the results is not a phasing strategy — the scores are not comparable, so the merge is arbitrary. Route a query to one index or the other, never to both (Federated Query).
Which parts of this corpus are queried often enough to justify recomputing them, and can the migration finish in a window you are willing to hold open?
when The corpus fits in one bounded run, and freezing chunking and metadata for that period is acceptable.
cost Doubled storage for the overlap and one large chargeable event. Buys the simplest possible story: one cutover, one rollback, one comparison (Atomic Publish).
when The corpus is large, the partitions are queried separately, and a natural canary is wanted.
cost A longer migration and a period where different partitions are at different versions. Safe only if a query never spans two partitions at different versions (Planning a Backfill).
when A minority of documents receive the overwhelming majority of queries, and the archive is genuinely reference material.
cost Two indexes, two encoders and a router that knows which is which — permanently. Buys a much smaller migration and an honest treatment of material nobody reads (Data Marts).
when Query distribution is extremely skewed and the store can hold both versions in separate collections.
cost Serving-path complexity, a long tail that never migrates, and a fallback path that must be correct under load. Buys a spend that follows actual usage.
when The evaluation shows no improvement on your corpus and your questions, which is a common and under-reported outcome.
cost A growing gap from whatever the ecosystem is doing, and an eventual migration from further behind. Buys the entire cost of the migration, which is the largest saving available (Compute Waste).
Whether a store gives you an alias or collection pointer that can be repointed atomically, whether a collection can hold more than one vector dimension, how a filtered count by metadata performs, and what the current embedding models and their input limits are all vary by product and change between releases. Design the migration so none of those is load-bearing — build beside, validate, switch one pointer — and verify the specific mechanics against current documentation before scheduling the run.
How to build it
Most important first.
- Write it down as a migration plan before any compute is spent: target version, target index, freeze list, validation gate, cutover mechanism, rollback window, retirement date for the old index (Planning a Backfill).
- Build into a new index or collection, never into the serving one. The old index keeps serving at full quality throughout, which converts a risky migration into a boring one whose worst case is wasted compute (Atomic Publish).
- Change exactly one variable. Freeze the chunker, the cleaning rules and the metadata schema for the duration, so a change in retrieval quality is attributable to the model and to nothing else (Chunking Pipelines).
- Reuse the ordinary embedding job with a target-version parameter. The work queue derived by difference — chunks with no vector at the target version — is already restartable, already idempotent, and already the right thing here (Embedding Pipelines, Idempotent Data Pipelines). Keep the incremental path writing to both versions for the duration of the migration. That dual-maintenance window is the part everyone forgets, and skipping it means the new index is missing precisely the documents that changed most recently (Incremental Processing).
- Validate with a fixed evaluation set, querying each index with its own encoder version, and record the comparison next to the decision. A migration approved on the basis of a demo query is a migration nobody can defend later (Evaluation Data Pipelines). Switch by moving one pointer, and pin the encoder version from the same place, so index and encoder can never be observed disagreeing (Rolling Back Data).
- Keep the old index for a stated rollback window, then delete it deliberately. Retention of the previous version is the difference between a rollback and a second migration (Storage Lifecycle).
What this actually promises
Naming the guarantee you do not have is worth more than naming the one you do — everything downstream inherits the weakest promise in the chain.
- During the build, the old index continues serving at full quality and the new one is incomplete and unread. That is the entire safety property, and it comes from building beside rather than from anything about the job (Atomic Publish).
- After a correct cutover, every vector reachable by a query is at one version — guaranteed by the pointer swap and by a completeness reconciliation, never by the job having finished without raising (Reconciliation).
- Nothing guarantees that the new model retrieves better. A newer model is a hypothesis, and the evaluation is what turns it into a decision (RAG Evaluation).
- Nothing guarantees that retrieval metrics are comparable across the cutover. They are comparable only if the chunk set, the evaluation set and the metadata filters were unchanged, which is why freezing them is part of the design rather than a nicety (Semantic Changes).
- The migration does not guarantee that deleted documents stay deleted. A re-embed driven from a stale chunk table will happily resurrect content that was removed from the source, and no check inside the job will notice (Deletion Requests).
Can I trust it?
A green pipeline is evidence that code ran. These four fields are the evidence that the data is right.
- The gate before cutover is a three-part comparison: completeness (chunks at the watermark equal vectors at the target version plus dead-lettered ones), fidelity (the chunk text hash stored with each new vector matches the current chunk row), and retrieval (a fixed question set, each index queried with its own encoder, compared case by case rather than as an average) (Validating a Backfill Before You Publish).
- It misses regression on every question not in the set, which is nearly all of them. A fixed set is a gate, not a measurement of quality — treat a passing comparison as "nothing obviously broke", never as "retrieval improved" (Golden Datasets).
- It also misses a corpus that is complete, faithful and evaluated on questions whose answers were themselves written from the old system's output. That circularity is the standing hazard of any evaluation set built without an explicit provenance rule (Evaluation Data Pipelines).
- A migration in progress creates a dual-maintenance window: two indexes to keep current, one serving and one being built. Whatever freshness the corpus promises has to be met by both, or the cutover publishes an index that is silently behind (The Freshness SLO).
- The bulk re-embed and the incremental path compete for the same external rate budget unless they are deliberately separated, and the bulk job always has work queued, so it always wins. A document edited this morning then becomes retrievable after the migration ends (Cost vs Freshness).
- The cutover itself is instantaneous from a consumer's point of view, which is the property that makes it acceptable to do during the working day. Everything expensive happened before it.
- The version string must identify everything that changes the output: the model, its revision, and the client library that tokenises and truncates the input. Two of those three routinely move without a schema changing anywhere (Semantic Changes).
- Dimensionality is part of the version. Stores that pin a dimension per collection force a new collection on a change, which is inconvenient and is also an honest reflection of what is happening (Breaking Schema Changes).
- Metrics defined over retrieval are not comparable across the cutover, so the time series needs a marker at the switch. A chart that runs smoothly through a model migration is a chart that will be misread ("What Changed?" — Deploy Markers and the Invisible Deploys).
- Rollback is a pointer move back to the old index, together with the encoder pin — both, atomically, because rolling back one of them creates precisely the version skew the migration was designed to avoid (Rolling Back Data).
- That rollback exists only if the old index still does. Deleting it on the day of the cutover converts every subsequent problem into a second full migration, which is the most expensive undo available in an agent platform (What Backfills Break).
- If a partial migration did get written into the serving index, the recovery is to finish it or to delete the target-version rows and start again — not to leave it. There is no state in which a mixed-version index is acceptable, because it fails silently rather than loudly (Deduplication).
What can go wrong
- A mixed-version index serving live queries, producing ranked results computed across two unrelated spaces with no error anywhere (Vector Data Engineering).
- Encoder and index versions skewed by an ordinary deployment, so retrieval breaks completely at a moment nobody associates with the corpus.
- The cutover performed on job completion rather than on a validation gate, so an incomplete index becomes the serving one (Missing Rows).
- The old index deleted immediately, removing the rollback the whole plan depended on (What Backfills Break).
- Two changes shipped together — new model and new chunker — leaving a quality movement nobody can attribute (Chunking Pipelines).
- The mitigation failing: a completeness check that counts vectors without filtering by model version, which reports a full index throughout a partial migration.
- "Re-embedding is a model upgrade." It is a data migration of every row in a derived dataset, with a dual-maintenance window, a validation gate and a cutover. Treating it as a version bump in a configuration file is how mixed-version indexes happen (Backfills).
- "We can migrate gradually, chunk by chunk, in place." Gradual in place is precisely the mixed-version state. Gradual is fine across separate indexes with separate cutovers; it is never fine inside one (Atomic Publish).
- "Same dimension count, so the vectors are compatible." Dimensionality is a shape, not a space. Two models with identical dimensions produce coordinates that are unrelated, and this misread is dangerous because the store accepts the write (Vector Search: Embeddings, Similarity and ANN).
- "The new model is better, so no evaluation is needed." Better on a published benchmark says nothing about your corpus, your chunk sizes or your questions. The evaluation is the only evidence that applies to you (RAG Evaluation).
- "The vector store handles versioning." Most will store whatever you write. Version discipline is a property of your schema and your pins, not of the store (Vector Data Engineering).
- "The job finished, so we can switch." The job finished with respect to a watermark. Completeness, fidelity and retrieval comparison are three separate gates, and finishing is none of them (The Pipeline Succeeded. The Data Is Wrong.).
- A re-embed sends the entire corpus to an external service again. It is a bulk egress event and it belongs in a design review, not in a configuration change — particularly if the classification of any document changed since the last run (Egress Security, Data Classification).
- Documents deleted since the last build must not reappear. The migration reads the chunk table, so a deletion that reached the index but not the chunk table will be resurrected by the very job that was supposed to be routine (Deletion Requests).
- The old index retained for rollback still contains vectors for deleted documents. A rollback window is a retention decision and needs to be stated as one, with the deletion path covering both indexes for its duration (Data Retention).
Operating it
- Distinct embedding model versions present in the serving index. It should be one. Anything else is an incident, and this is the cheapest possible detector for the failure this lesson exists to prevent (Data Tests).
- Coverage at the target version — vectors at target divided by chunks at the watermark — as the progress signal, rather than a percentage over a moving denominator (The High-Water Mark).
- The encoder version recorded on every retrieval trace, compared continuously against the index version. Skew should page immediately (Agent Observability Data).
- Retrieval evaluation metrics with a deployment marker at the cutover, so the discontinuity is annotated rather than interpreted as a trend ("What Changed?" — Deploy Markers and the Invisible Deploys, Regression or Tuesday? Telling a Real Change from Noise).
- Units of work remaining and dead-lettered, published before the run and reconciled after it, attributed to the migration rather than to general platform cost (Cost Attribution).
- At ten times the corpus, the migration no longer fits in one window and becomes a partitioned, resumable programme with per-partition progress. Partitioning by tenant or document class also gives you a natural canary (Planning a Backfill).
- Per-partition cutover is legitimate as long as a single query never spans two indexes at different versions. Mixed versions across indexes that are queried separately is fine; mixed versions within one index is never fine.
- At a hundred times, some corpora are never fully re-embedded. Tiering — the actively-queried corpus migrates, the archive stays at the old version behind its own encoder — is an honest answer, provided the tiers are separate indexes and the router knows which encoder each one needs (Data Marts).
- Consumer count changes the cutover, not the build. More independent retrieval paths means more places holding an encoder pin, and the pin has to come from one source or skew becomes a matter of time (Data Contracts).
- A full re-embed is the largest single chargeable event an agent platform has: every chunk sent to a metered external service again, in one bounded window. Everything else in this module is small beside it (What Actually Drives Data Platform Cost).
- Building beside doubles vector storage for the overlap period and doubles it again if the rollback window is long. That is the price of reversibility and it is almost always worth paying (Storage Lifecycle).
- The dual-maintenance window costs the incremental path twice for its duration, which is a reason to keep migrations short rather than a reason to skip the dual writes.
- The cheapest optimisation remains not doing the work: a keyed sink means an interrupted migration resumes rather than restarting, and a difference-derived queue means nothing is ever paid for twice (Compute Waste).
- Building beside costs a second full index and a longer migration; it buys a serving path that is never degraded and a rollback that is a pointer move. There is no version of in-place re-embedding that has either property.
- Freezing the chunker and metadata for the duration delays other improvements and is what makes the evaluation interpretable. Shipping two changes together is faster and leaves you unable to explain the result to anyone, including yourself.
- A long rollback window costs storage and buys the ability to undo a decision after the evidence arrives — which, for retrieval quality, is usually weeks rather than hours, because most regressions are reported by users rather than by monitors.
Dataset review questions
This lesson uses the shared review exercise.
Where this applies
Almost nothing here is universal. These labels say what each claim is specific to, and where a different engine, format, warehouse or scale would differ.
- GENERALThat vectors are only comparable within one model version, and that the safe migration is build-beside-then-switch, holds for every embedding model and every vector store. What varies is whether the store gives you an alias or collection pointer to switch, or whether you have to hold the target index name in configuration and deploy it.
- SCALE-SPECIFICBelow a corpus that re-embeds inside a single run against an idle index, in-place replacement is correct and the second index is unnecessary machinery. Everything about dual maintenance, per-partition cutover and rollback windows becomes mandatory once the build no longer fits in a window where nobody is querying.
- CLOUD-SPECIFICAgainst a managed embedding endpoint the migration is bounded by a request-rate limit you cannot raise on the day you need it, so the schedule is set by someone else; with a self-hosted model on your own accelerators it is bounded by capacity you can add but must operate. The plan is identical and only the duration and the failure symptom differ.
Where the depth lives
This domain teaches how data moves and how you know it arrived intact. It hands the rest off by name.
- — DevOps / Production Engineering owns the cutover mechanics this borrows — blue/green, canary traffic, one pointer moved, and the rollback window that makes a decision reversible. What is unusual here is that the artefact being promoted is a dataset rather than a binary, so the canary needs a corpus and an evaluation set rather than a subset of instances.
- — Distributed Systems owns what happens when the index pointer and the encoder pin are read by many independent replicas that observe the switch at different moments, and why a configuration change is not an atomic operation across a fleet.