# Blue-green deploys for embedding changes
## Why
Changing the embedding model changes the dimension, which means a new index. Re-embedding in place on the serving index is impossible (dimension is frozen) and destructive.
## Steps
1. **Build green.** Create `docs-v2` (new index) or a `v2` namespace with the new dimension and metric. Ingest the full corpus there.
2. **Verify green.** Stats totals match the corpus; sample queries return sane results; run your recall eval set against green and compare to blue's baseline.
3. **Dual-read briefly.** Send a slice of production queries to green and log both result sets. Investigate divergences before full cutover.
4. **Flip.** Update the serving config to the green index or namespace. One config value, one deploy.
5. **Hold blue.** Keep the old index for a rollback window (days, not hours). Rollback is a config flip back.
6. **Delete blue.** After the window, delete to stop billing. Confirm no code still references the old name.
## Traps
1. Flipping before the ingest finished: green serves partial data and nobody notices for a week. Gate the flip on stats totals.
2. Two writers during dual-read: writes must go to both or to green only with a backfill; pick one and enforce it.
3. Forgetting blue bills: set a calendar reminder at flip time for the deletion. Pod indexes especially.