# LFM2.5-DSpark: target revisions and draft compatibility

A target update changes the DSpark pair's identity, so an accepted draft configuration should not silently certify every later checkpoint from the same family.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-20
Original announcement: https://www.liquid.ai/blog/lfm2.5-dspark
Canonical URL: https://retrivium.ai/retrospectives/retro-liquid-text-dspark-target-identity/

A target update changes the DSpark pair's identity, so an accepted draft configuration should not silently certify every later checkpoint from the same family.

## The paired publication

The [DSpark release](https://www.liquid.ai/blog/lfm2.5-dspark) publishes draft artifacts for existing targets. That makes compatibility a relationship between identified components. An updated target can remain recognizably related while changing the behaviour against which proposals are checked. Family continuity is therefore weaker evidence than a fixture covering the actual pair.

## The earlier target sequence

The preceding [hybrid release](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact release](https://www.liquid.ai/blog/lfm2-5-230m) establish earlier family artifacts. They locate the drafter's purpose historically, but do not create an unrestricted compatibility promise for future targets. Each artifact still has its own revision and implementation requirements.

The distinction is important during maintenance. A routine model update can leave the API unchanged while changing the internal reference for speculative execution. A deployment record that tracks only the endpoint can miss that the paired configuration has materially changed.

## A selective-upgrade example

Imagine keeping the draft file while replacing the target with a newer post-trained revision. If the resulting answers remain useful, that is encouraging but does not isolate whether acceptance behaviour changed. If performance changes, the cause might be compatibility, workload mixture or another revised setting.

Retain a target-only run for the new revision and a separate paired run. Those controls distinguish the new target's own behaviour from effects introduced by reusing the old draft. They do not require assuming that the update is either harmful or automatically beneficial.

## Rollback needs component identity

A rollback described only as restore the previous model can be ambiguous when the system contains both target and draft. Restoring one file while leaving another changed does not reproduce the old configuration. Runtime settings and sampler assumptions also belong to the paired record.

Store the reviewed pair as a configuration artifact with references to its members. If a partial upgrade is intentional, label it as a new configuration awaiting its own acceptance evidence. This prevents convenience labels from concealing which combination actually produced a result.

## The retrospective lesson

The release introduces a useful acceleration relationship, and maintaining that relationship becomes part of operations. The draft is neither a universal family accessory nor a component whose identity can be forgotten after initial installation.

The conclusion is to treat target replacement as a paired compatibility event. Verify the task contract and interpret performance only after identifying the complete configuration. That makes upgrades and rollbacks explainable without inventing a claim that all related targets accept an old draft equally well.

Further analysis: [Reproducible inference stacks: preserving a GPU pilot’s result](/journal/software-stack-reproducibility/); [GPU hosting for multimodal models: count more than text](/journal/multimodal-gpu-hosting/).