The data-centric view: system quality is more often limited by the data than by the model. Datasets and embedding indexes are versioned (DVC / lakeFS / Iceberg snapshots), and lineage is traceable: which index, from which documents, with which chunker, with which embedding model.
The argument is older than LLMs. Sculley et al., “Hidden Technical Debt in Machine Learning Systems” (NeurIPS 2015), observed that data dependencies cost more than code dependencies because nothing like a compiler or linker tracks them: an input signal changes upstream and the model degrades silently. Gebru et al., “Datasheets for Datasets” (2018), proposed documenting how a dataset was collected and processed for the same reason. A retrieval system has the same shape: an answer was wrong — was it the model, the prompt, a document that was never indexed, a chunk split mid-table, or an index built from last month’s export? Without lineage the question has no answer, and a fix cannot be shown to work.
What goes into git is not the datasets but an immutable manifest: object identifiers and their hashes, the schema, the parser and chunker versions, the embedding model, the access-policy version. The data itself lives in versioned object storage. Every eval result (51) and every production answer log (57) records the manifest id it ran against, so a regression can be bisected across data versions the way code is bisected across commits.
Changing the embedding model = a full reindex = an expand–contract migration (17), not an in-place one: vectors from two models are not comparable, so the new index is built beside the old, evaluated, switched by alias, and the old one dropped after a rollback window.
Limits. Versioning everything is expensive for large, fast-changing corpora; snapshot at the granularity you need to reproduce a result, not every write. And versioned data still carries its deletion obligations: a snapshot that keeps erased personal data forever breaks retention (36).