Liquid AI published its new decision model’s benchmark table twice on 7 October, once in the model card and once in the launch blog post. The card’s table has eight rows. The blog’s has seven. The missing row is the only one where the 3B model loses to a competitor a third larger, and dropping it takes d1-3B’s lead over that competitor from 0.9 points to 1.8.

Both documents say so openly, which is what makes this checkable rather than an accusation. The question worth asking is narrower than “did they cheat”: it is which of the two documents tells a reader what the model does, and the answer is not the one with the better mean.

The two tables, row by row

The release is a pair of open-weight models in a category Liquid calls decision models: they take a state and a set of named questions and return typed answers “in a single forward pass” with, as both documents put it, zero output tokens. No generation, no parsing. d1-3B is built on LFM2.5-VL-3B; d1-omni-600M is a 587M encoder model that also reads images and up to 30 seconds of speech.

Under “Benchmarks as decisions”, the d1-3B model card lists eight public benchmarks against Decider 4B and Decider 2B. Seven of those eight reappear in the launch post. The eighth is HelpSteer2, and on it d1-3B scores 36.7 against Decider 4B’s 42.0 — a 5.3-point loss, the largest single gap against d1-3B anywhere in either table.

The arithmetic follows directly. Across all eight rows, d1-3B means 77.1 and Decider 4B means 76.2: a lead of 0.9 points. Across the blog’s seven, d1-3B means 82.9 and Decider 4B 81.1: a lead of 1.8. Both means are printed in their respective documents and both are correct for the rows above them. The row that disappears is the one doing the most work.

The blog’s sentence on this is unhedged: “d1-3B leads with a mean of 82.9, the highest in the table and ahead of Decider 4B (81.1).” True of that table. The card’s eight-row mean, 77.1, appears without a comparable sentence.

The stated reason belongs to the other model

Liquid does give a reason, and it is in the d1-omni-600M card: “HelpSteer2 is left out: it may overlap with d1-omni-600M’s training data.” That is a sound exclusion, and declaring possible contamination against your own model is the opposite of hiding something.

But read what it covers. The concern is d1-omni’s training data. The blog’s table scores four models in one grid, so excluding the row for omni’s sake removes it for d1-3B as well, and d1-3B’s own card carries that same row with no contamination note at all. One model’s disclosed data problem silently doubles a different model’s margin. Nothing in either document says the exclusion was made for d1-3B, and nothing says it wasn’t; the blog simply presents seven rows and names the winner.

A reader who only opens the launch post sees a model beating a larger competitor by 1.8 points on seven benchmarks. A reader who only opens the card sees 0.9 points on eight. Neither document is false. They are differently shaped, and the shape is the finding.

Counting the rest of the comparisons

A single omission is thin evidence of a pattern, so I tabulated every comparison in both documents. The pattern does not hold, and three of them run against Liquid.

The vision table compares d1-3B with its own base model across eleven image benchmarks. d1-3B is below the base on six of the eleven — AI2D, CV-Bench, MME, MMStar, POPE and VisualWebBench — and above on five. The mean, 74.1 against 73.9, survives almost entirely on one row, VL-RewardBench, where d1-3B gains 14.1 points. That table is published in full, losses included, on the card.

The second runs harder against them. d1-omni-600M’s Decision Index score is 15.95, and the card prints it in the same leaderboard as Decider 2B’s 28.97 — a model the blog elsewhere says omni outperforms on text benchmarks. On the index it scores 45% lower than the smaller competitor it beats on the other table, and that figure is in the blog too: “It scores 15.95 on the same index.”

Third, Liquid declines two flattering options outright. It reports no inference numbers at all for omni, saying it “is an early research release and is under active development,” where a latency table would have been easy. And on the audio capability that is the model’s novelty, the blog says plainly that “Dedicated audio decision benchmarks are currently an open problem” rather than producing an internal one.

So the HelpSteer2 row is not an instance of a habit. It is the one place where the harder number lives in the less-read document, in a release that otherwise publishes its losses.

What the card tells you that the post does not

The caveats a reader actually needs are all on the cards and none are in the post. d1-omni’s audio was trained only on “requests between an English speaker and an assistant,” and clips cut at 30 seconds. With images, its state and question text is truncated to 896 tokens. It should be run in float16 or float32, not bfloat16, which “changed the top answer on 0.8% of text and 1.7% of audio rows.” d1-3B’s 8 ms figure on an RTX 4090 requires CUDA graphs; without them “a single question takes 16 ms,” exactly double.

One detail deserves credit for honesty of a kind that is rare. d1-3B’s vision score was also measured with the images removed, where the same questions score 45.1 — the card’s own check that the model is reading pictures rather than guessing from the options. That is a negative control a vendor had no obligation to run.

All of these numbers are Liquid’s own, on Liquid’s own harness. The Decision Index rows for both models were scored by Liquid with the official scorer and are, in the card’s words, “not a leaderboard submission,” while every competing row comes from the public leaderboard. No third party has reproduced any of it.

Both cards point readers to the launch post with a link to liquid.ai/blog/open-d1, which returns 404. The post lives at /blog/d1-open, which is the URL in the cards’ own citation block a few lines further down. A reader following the prose link lands on nothing; a reader copying the BibTeX gets there. Minor, and a reminder that the two documents were assembled separately — which is the same reason their tables differ.