# d1 vision launch: hosted decisions before open weights

The hosted d1 vision announcement made policy questions over text and images an application interface before the later open-weight release.

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/d1-hosted-vision-before-open-weights/

The hosted d1 vision announcement made policy questions over text and images an application interface before the later open-weight release. Reading those stages separately explains what developers could test immediately and which claims about local reproducibility still required additional artifacts and evidence.

## What became available first

The [vision-enabled d1 post](https://www.liquid.ai/blog/d1-decision-model) sits after earlier [hybrid local-model work](https://www.liquid.ai/blog/lfm2-5-8b-a1b) and [compact deployment work](https://www.liquid.ai/blog/lfm2-5-230m). Its immediate contribution is a hosted decision surface. That surface can expose useful behavior without exposing the exact weights, processing pipeline or deployment configuration behind it. A retrospective should describe the interface available at that date rather than silently importing capabilities from the subsequent public checkpoints.

## The policy question becomes executable configuration

A classifier with fixed labels hides much of its task definition inside training. A question-driven interface moves part of that definition into the request. This makes adaptation convenient, but also makes wording a behavioral dependency. Changing the meaning of acceptable damage or sufficient evidence can change the decision rule without changing the endpoint name.

For an illustrative inspection task, compare a cosmetic scratch with a defect that prevents assembly. A generic question about damage may combine them; a policy-specific question can distinguish them only if the supplied evidence supports the distinction. The benefit is explicit task definition, not automatic correctness.

## Image evidence changes answerability

A text description may omit the very property needed for a visual decision. Conversely, an image can lack the scale or viewpoint needed to judge a defect. Combining both inputs does not create missing information. An application must distinguish a confident-looking selection from an answerable question. A useful fixture therefore includes an obscured feature and a description that conflicts with the image, rather than only clean examples.

The resulting disagreement should be preserved for review. Automatically preferring text or image would replace one uncertain inference with an undocumented policy choice.

## Hosted access limits causal diagnosis

When behavior changes, an API consumer may not know whether the cause is a model update, a processor adjustment or an instruction change. Keeping exact requests and dated responses helps identify the boundary of available evidence. It does not make an unpinned hosted implementation reproducible. Describe observed outputs as observations of that service at that time, not as permanent properties of an entire model family.

## Why the release sequence matters

The event established an alternative to generating prose for every application judgment. It also created a new versioning surface: questions, answer options and input evidence together define the decision task. The later weight release can change who controls execution, but it does not erase the earlier need to specify policy. That is the durable lesson of the sequence: distribution and decision design are separate sources of control, and neither alone establishes a trustworthy outcome.

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