Silent Truncation: A Diagnostic Story About What Your Model Actually Read
I maintain a set of dense technical documents that I run through frontier AI models for review. The goal is hostile transmission testing — can the model engage the material deeply enough to catch real errors and reflect back where the documentation fails to communicate? I’ve been running this across multiple models for months. Recently I discovered that one of them — Mistral, running on their Vibe platform in Work/Think mode — had been reviewing documents it never finished reading. And it never told me.
What Happened
I was feeding documents one at a time via URL. My primary technical document is roughly 243,000 characters. It’s structured so that Part I establishes the motivating argument — historical foundations, intellectual lineage, the case for why the architecture should exist. Part II, more than half the document, contains the actual architecture. Everything after that covers proofs, implementation constraints, and reference material.
Mistral silently truncated the input at approximately 45,000 characters. The truncation occurred on both file upload and URL fetch. Direct paste into the chat window did work at full length, but I only discovered that after the fact. Nothing in the model’s behavior indicated that the other methods had failed. No warning, no error, no disclosure.
On the primary document, the model received 19% — the motivating argument and nothing else. The entire architecture was missing. It cut off mid-sentence. And then it reviewed the document.
What the Review Looked Like
Mistral didn’t say “I was unable to read the complete document.” It produced a review. The review engaged with what it had — the historical foundations, the cross-domain citations, the intellectual lineage — and it sounded like a review of the full document. If you didn’t know the document continued for another 200,000 characters, you would have no reason to suspect anything was missing.
The reaction was substantive. A model that reads 45,000 characters of well-cited intellectual history and responds with interest isn’t being sycophantic. It’s responding to a genuinely compelling argument. The problem isn’t that the reaction was wrong. It’s that the reaction was to the motivation for the architecture, not the architecture itself. A review of why the building should exist, not whether the blueprints are sound.
How I Discovered It
The sixth document I uploaded contains two major sections covering different intellectual traditions — one in the first half, another equally substantial in the second half. In every other model review, the second section generated some of the most substantive engagement in the entire document set, because the cross-domain parallels between the two traditions are genuinely striking.
Mistral engaged the first section thoroughly. On the second — complete silence. Not a word. Its absence was conspicuous.
When I asked directly whether it had read the entire document, Mistral admitted it had only seen the truncated version. Then it got worse. Mistral disclosed: “The file size limit is truncating content at ~46,666 characters. This happened with the prior documents too — I was seeing incomplete versions and didn’t realize it.”
Every document I had fed it. Not just this one. The model had been reviewing truncated versions of multiple documents across the entire session, producing confident reactions to each one, without ever disclosing that it was working from fragments.
The Retroactive Contamination
I had been running documents through multiple models over a period of months — building a picture of where the documentation succeeded and failed based on how each model engaged with it. Some pushed back. Some accepted too easily. Some caught real errors I subsequently fixed. I was using these reactions as signal to improve the documentation.
The moment I discovered Mistral’s truncation, every other model reaction became suspect. Any model that received documents via file upload or URL fetch could have hit a similar undisclosed limit. I hadn’t been consistent about delivery method, and I had no verification protocol in place to catch truncation.
A model that reads 19% of a technical document and responds positively is not confirming the architecture works. It’s confirming that the introduction is well-written. Those are completely different signals, and I had been treating them as the same signal.
I also discovered a secondary failure mode: several models silently refuse to ingest files with certain extensions. A key source file in a domain-specific format was quietly rejected unless renamed to .txt. No error message. Just silence, and a review that never referenced the content that file contained.
The Fix
The verification protocol is simple. Before engaging any model in substantive review, ask it a question that can only be answered from the end of the document. If the model can answer correctly, it received the complete document. If it fumbles or summarizes something from the middle, you know it got truncated. Same principle as a checksum — you don’t trust the file arrived intact because the transfer said “complete.” You verify the content at the boundary.
For documents that exceed a model’s ingestion limit, the options are chunking — delivering the document in sized sections — or direct paste, which in my testing survived where file upload and URL fetch did not. Either way, the verification question comes after every delivery.
The Broader Lesson
There are three distinct silent failure modes I’ve now documented across frontier models when handling large documents:
**Silent truncation.** The model’s file reader has an undisclosed character limit. Content beyond that limit is dropped without notification. The model reviews what it received as if it were the complete document.
**Silent file rejection.** The model’s file handler refuses to process certain file extensions. No error is reported. The file is simply absent from context.
**Silent context collapse.** (Documented in a previous post.) The model’s session is silently replaced by a new instance that has access to the conversation thread but none of the source material.
All three share the same property: the failure produces no signal. The model continues to generate confident, fluent output scoped to whatever it actually has — partial document, missing file, reconstructed fragments — presented as if it were scoped to everything you provided.
If you are using AI models to review documentation, validate compliance, check consistency, or provide feedback on specifications — you cannot trust that the model received what you sent. Verify at the boundary. Ask about the end. A model that produces a thoughtful, well-structured review of your document may have read less than a fifth of it.
The review will still sound confident. That’s the problem.
(Full disclosure: this document drafted with Claude Opus 4.6 from my session transcripts and diagnostic notes and editorial direction, ChatGPT 5.6 Sol assisted with the hero image)
Bryan Needs a Title for His Home Page