# Open d1: portable weights and browser execution

Open d1's downloadable weights make browser experiments possible to investigate, but weight availability alone does not establish a complete browser execution path.

Author: Retrivium editorial team
Language: en
Analysis published: 2026-11-03
Event date: 2026-10-07
Original announcement: https://www.liquid.ai/blog/d1-open
Canonical URL: https://retrivium.ai/retrospectives/retro-liquid-d1-weights-browser-portability/

Open d1's downloadable weights make browser experiments possible to investigate, but weight availability alone does not establish a complete browser execution path.

## The artifact boundary

The [release announcement](https://www.liquid.ai/blog/d1-open) publishes decision-model artifacts. A browser implementation must still support the selected representation, input preprocessing and output contract. This article does not assign an unverified browser-support date; it explains which additional evidence is required before a portable artifact becomes a reproducible browser application.

## Earlier model and interface context

The [encoder announcement](https://www.liquid.ai/blog/lfm2-5-encoders) and [hosted d1 announcement](https://www.liquid.ai/blog/d1-decision-model) precede the weight publication. They describe different parts of the story: an architectural direction and an accessible decision interface. Neither can establish that an unrelated browser backend reproduces the same calculation or supports every announced modality.

A hosted result is useful as a behavioural reference only when the compared tasks and inputs are aligned. It should not be treated as a complete numerical specification for a different artifact, especially when the exact hosted revision is not available in the record.

## A client-side experiment

Imagine a browser demo checking a catalogue image against a question. It must turn the uploaded file into the expected model input and preserve the meaning of the decision output. Showing a plausible result proves less than demonstrating that the correct artifact and preprocessing path produced it.

Keep a small fixture containing the source image, question and recorded intermediate representation. Compare the intended evidence rather than just the displayed label. If the browser resizes or transforms the image differently, an output difference may originate before the model itself executes.

## Portability has several layers

Downloading a file, loading it and obtaining a result are distinct milestones. A runtime can recognize an artifact while lacking a needed operation or modality path. Conversely, an implementation limitation does not establish that the original model lacks the capability described by its publisher.

Numerical agreement also needs a defined interpretation. Exact output equality may be inappropriate after a changed representation, while a single matching label can hide large differences near a decision boundary. The acceptance rule should state what agreement is sufficient for the intended application and why.

## The retrospective lesson

The release expands the set of implementations that can be attempted and inspected. Its contribution should not be inflated into a claim that every execution environment was immediately supported. That distinction preserves both the value of downloadable artifacts and the engineering work needed to use them.

A defensible browser claim names the artifact, backend and tested input path. Portable access begins the investigation; reproducible execution completes a more specific part of it.

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