Column decomposition is the failure worth studying because the output is well formed. Vision returned three model names in sequence, then three memory figures, with the speed and status columns appended at the end of the document [9]. Nothing is garbled, the characters are all present and correctly grouped, and which speed belongs to which model cannot be recovered [9]. The 27B model kept the rows [10]. The detectability argument follows from that directly: syntactically perfect output with plausible structure carries no error signal, so downstream it reads the same as a correct pass [11].
Put a number on it. The table is four columns by three rows [2]. If the ordering within each recovered column carries no reliable information, which is what the account claims [9], then aligning three speeds to three models has 3! = 6 candidate mappings, and a consumer that guesses is right about 17 percent of the time [20]. Nothing in the output says which case you are in.
All eight of Vision's errors are character substitutions: IQ4_XS read as I04_XS, cloud as cLoud twice, tok/s as tok/5, two characters inside a code string, an em dash flattened to a hyphen, an arrow to -> [5]. None of them is structural [21]. A character error rate therefore scores the run at eight errors and charges nothing for the relation that disappeared [21]. Vision also misread the quantization label of the model it was losing to, which is a nice touch [5]. The author's own reading is that he had mislabeled the task: Vision is dedicated to character recognition, not to document understanding [17].
The cheapest step in the method is the one that made the rest of it valid. His first render was broken, because the monospace font had no Korean glyphs and a label came out as tofu boxes [4]. Ground truth that is already wrong at the moment you fix it voids every measurement taken against it, and checking the image costs about thirty seconds [4].
Speed is the figure that needs the most care. Vision ran 300 times faster [8], against a model identified only as a 27B at IQ4_XS quantization holding 15GB resident [1]. The note names no checkpoint, no hardware and no OS build, and reports a single rendered image with no repeat runs [18]. For 300x to transfer you would need the same quantization on comparable silicon and the same Vision implementation underneath. What does transfer is the shape of it: a zero-footprint system call against a 15GB resident process [1] is not a comparison you run per page inside a loop.
The identifier result is the one I would act on first. On the adversarial line A0-1lO9-B8 [2], the author enlarged the render and confirmed that the font draws digit 0 with a slash through it and capital O as a plain oval, so the two glyphs are visibly different, and both engines still misread the string [13]. More pixels do not address that [13]. His conclusion is that the whole tool class is untrustworthy wherever homoglyphs change meaning, and that the remedy is a checksum or human confirmation rather than a better engine [14]. He then proposes Vision as the first pass with escalation only for documents where reading order carries meaning, and corrects the rule himself because column-shredding is not detectable [15]; the published text stops mid-sentence at the correction [22]. The version the evidence supports routes by document type before reading, not by confidence after.
