Meridian Line swaps the embedding model behind its bill-of-lading Vector Search index from one that produces 768-dimension vectors to a newer model that produces 1536-dimension vectors, but leaves the existing index and its stored vectors untouched. What happens?

An embedding model defines the vector space its outputs live in, including dimensionality, and vectors produced by different models are not directly comparable even when dimensions happen to match, because the geometry encoding semantic similarity differs between models -- so swapping the embedding model requires re-embedding the entire source corpus and rebuilding the index, not simply pointing new queries at the old vectors. There is no automatic padding or dimension-reconciliation mechanism that makes an index transparently support two different embedding spaces at once; a 768-dimension stored vector and a 1536-dimension query vector cannot even be compared by the standard similarity computations, so this option describes behavior that does not exist. Silently truncating new 1536-dimension query vectors down to 768 dimensions would not restore compatibility either, since the retained dimensions of a different model's embedding do not correspond to the same semantic axes as the old model's -- comparing them would produce meaningless similarity scores, not merely degraded ones. Embedding dimension and, more fundamentally, embedding model choice are directly relevant to retrieval quality; changing either without rebuilding invalidates the index's semantic consistency. Exam framing: understanding the consequences of an embedding-model choice for the index is a named Data Preparation objective, and this operational failure mode is exactly what that objective is testing when applied at the Application Development layer.