# LFM2.5 Q4_0: quantized migration and exact identifiers

Replacing a converted checkpoint with trained LFM2.5 QAD should preserve exact-identifier tests, because fluent output can conceal the errors most consequential to structured clients.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-08-19
Original announcement: https://www.liquid.ai/blog/qad
Canonical URL: https://retrivium.ai/retrospectives/retro-liquid-qad-precision-migration/

Replacing a converted checkpoint with trained LFM2.5 QAD should preserve exact-identifier tests, because fluent output can conceal the errors most consequential to structured clients.

## The field that must not drift

A part code, account reference or document identifier is not merely another phrase in an answer. A single altered character can point to a different entity. An application that uses the field as a lookup key therefore needs a stricter acceptance contract than one that reads the answer only as explanatory prose.

## Why this release is a migration event

The [QAD announcement](https://www.liquid.ai/blog/qad) supplies a trained quantized artifact rather than an ordinary conversion alone. The earlier [hybrid release](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact release](https://www.liquid.ai/blog/lfm2-5-230m) provide preceding family context. They do not establish identical behaviour between an old converted file and the newly published student.

This makes the artifact change worth recording even when both filenames advertise the same format. A successful load establishes execution compatibility; it does not establish that the application will receive identical structured fields on every relevant input.

## A source-grounded fixture

Use a maintenance note containing similar identifiers attached to different components. The question should name the component whose identifier is required. The expected result must come from that association, not simply from finding any code-shaped string in the note.

| Failure category | Why the client cares |
| --- | --- |
| Correct-looking code for the wrong component | A lookup succeeds but returns the wrong entity. |
| Normalized text that changes a meaningful symbol | Human readability hides a changed key. |
| Invented completion for an absent field | The output falsely implies source evidence. |

## Normalization needs ownership

Some applications deliberately normalize spacing or case. Those transformations should be explicit and tested against the identifier's actual semantics. A normalization useful for natural-language search may be inappropriate for a field where the exact source representation matters.

Keep raw extraction separate from the application's normalized key. If a mismatch appears, the record can then distinguish model output from later transformation. Without that boundary, the migration may be blamed for an error introduced after inference or credited for a correction made elsewhere.

## Interpreting the migration

A fixture failure does not establish that trained quantization is generally worse. A passing fixture does not establish universal equivalence either. Both observations concern an identified artifact, execution path and class of input.

The retrospective lesson is to preserve consequential invariants across a model change. Exact-identifier checks make the migration accountable to the consuming system's real contract, while leaving broader model-quality claims to evidence designed to support them.

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/).