# Introducing d1: versioning a hosted decision question

The hosted d1 launch made the decision question part of an application's behaviour, so editing that question can constitute a release without changing the model name.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-05
Original announcement: https://www.liquid.ai/blog/d1-decision-model
Canonical URL: https://retrivium.ai/retrospectives/retro-liquid-d1-vision-policy-version/

The hosted d1 launch made the decision question part of an application's behaviour, so editing that question can constitute a release without changing the model name.

## The hosted event

The [October announcement](https://www.liquid.ai/blog/d1-decision-model) introduces visual and text decisions through an API. Its bounded output does not remove the importance of the question being asked. A stable model endpoint can implement different application rules when the caller changes what condition the model is supposed to decide.

## Earlier publication context

The earlier [hybrid release](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact release](https://www.liquid.ai/blog/lfm2-5-230m) establish the preceding programme. They do not turn the hosted launch into an open-weight event. Keeping the access boundary clear matters when reconstructing a policy change: the application can revise its question without publishing or replacing any local checkpoint.

The model reference is therefore necessary but insufficient for identifying behaviour. The effective configuration includes the question and the evidence supplied with it. A history containing only endpoint names cannot explain every change visible to the application's users.

## A catalogue-policy example

Suppose a catalogue first asks whether an image contains the requested product, then changes the question to whether it contains only that product. A scene with additional objects can legitimately change classification. The model has not necessarily become inconsistent; the application is asking a more restrictive question.

Version the old and new wording with the expected difference on a concrete fixture. This makes the intended behavioural change reviewable. Without such a record, a later operator may try to correct model drift when the actual cause was a deliberate change in the application's predicate.

## Policy review is not prompt decoration

The question determines which property matters. Small wording edits can change the task's scope rather than merely improve style. A review should therefore ask whether the new wording changes answerability, exclusions or the role of missing evidence, not only whether it sounds clearer.

Keep returned outputs from the same fixture under both versions. This is not a claim that the API guarantees identical repetition. It is a way to make the intended policy difference explicit and separate it from unexplained variation that still needs investigation.

## The retrospective implication

The hosted launch is useful as an interface event: it exposes decisions without requiring ordinary generated explanations as the final contract. It also places responsibility on the caller to identify the question that gave a decision meaning.

The conclusion is to treat a changed decision question as a behavioural artifact. Preserve its revision alongside the model reference and input evidence. That produces a more accurate application history than assuming that only a new model endpoint can change what the system does.

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