# Introducing d1: visual conditions versus text-only labels

The d1 vision launch changed the evidence available to a decision, so a text-only fixture cannot establish that an image-dependent condition is being evaluated correctly.

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-image-condition/

The d1 vision launch changed the evidence available to a decision, so a text-only fixture cannot establish that an image-dependent condition is being evaluated correctly.

## The October interface change

The [hosted announcement](https://www.liquid.ai/blog/d1-decision-model) introduces decisions over text and images. A bounded answer can look similar regardless of which evidence produced it. That makes input verification especially important: the final label alone cannot show that the image was present, relevant or interpreted through the intended path.

## Earlier on-device context

The preceding [hybrid release](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact release](https://www.liquid.ai/blog/lfm2-5-230m) provide chronological context for the programme. They do not establish the new hosted interface's visual behaviour. Nor does a successful text decision prove that the image branch is working, even if both tasks use the same endpoint and output schema.

The new event should therefore be understood as an evidence-contract change. The system can ask a question whose answer depends on pixels, rather than only on the words that describe an image. Those are different tasks whenever the description omits decisive details.

## A product-condition example

Imagine checking whether a package seal is visibly intact. A text field describing the product type cannot establish the seal's condition. If the fixture contains only that field, a plausible answer may demonstrate a language association while failing to test the intended visual condition.

Construct paired examples where the description remains stable and the relevant visual evidence changes. Their purpose is to make dependence on the image observable. This is an acceptance design, not a claim that the announced model achieved a particular accuracy on such a fixture.

## Missing and ambiguous evidence

A missing image and an image that does not show the seal are different failures. The first concerns delivery of input; the second concerns answerability from available evidence. Combining them as incorrect predictions prevents the application from distinguishing a transport problem from a genuinely unresolvable visual question.

Preserve the supplied file and the decision question in the record. If preprocessing changes the crop, retain that transformation too. The effective evidence may differ from the user's original upload, and the output should be interpreted against what the model actually received.

## The retrospective consequence

The hosted launch expands which questions can be posed directly to the decision interface. Its value is clearer when the evaluation also changes to reflect the new evidence, rather than reusing a text benchmark and calling it visual validation.

The conclusion is to test dependence, not just plausibility. An image-capable decision path should be evaluated with cases where visual evidence matters and with explicit handling of cases where that evidence is unavailable.

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