Our QA judge called articles incomplete. It caused the truncation.

A validator that cut drafts before judging them, then reported the cut as a critical failure. The longer the article, the more certainly it failed.

Article cuts off mid-sentence in the final section ('makes you sc'). This is a critical structural failure that renders the piece unpublishable.

Symptom

An editorial QA step rejected a 2,212-word draft with a high-severity issue that read, in full: the article cuts off mid-sentence in the final section, quoting the fragment it stopped at, and calling this a critical structural failure that renders the piece unpublishable.

The article did not cut off mid-sentence. The full text ran on for another five and a half thousand characters and ended in a conclusion.

What we thought it was

The obvious reading is that the generator produced a truncated article. Language models do stop early. They hit token limits, they lose the thread on long structured pieces, and a draft that ends mid-clause is a familiar enough failure that nobody questions the diagnosis.

So the response was to treat it as a generation problem. Drafts were shortened until they passed. That worked, in the sense that shorter articles stopped being flagged, which is exactly the kind of evidence that confirms a wrong theory. The fix appeared to work, so the theory appeared to be right.

What made it hard to see is that the failure scaled with length. The longer and more thorough the article, the more certainly it failed QA. That reads as a model struggling with long-form output. It is equally consistent with something downstream cutting the article before anything ever judged it.

Root cause

The validator truncated the draft before sending it to the judge.

src/validate.ts:28 defined a maximum content length of 8,000 characters, and the editorial check sliced the draft to that length before passing it to the model. The judge then received a document that genuinely did stop mid-sentence, and reported that accurately. The finding was correct. The input was wrong.

The draft in question was 13,520 characters. The fragment quoted in the failure message sits at character 7,989 of the stored content. The sentence it belongs to is complete in the original and reads perfectly; it was cut eleven characters before the truncation boundary.

Two things made this worse than a simple off-by-one.

The first is that the penalty was severe. The issue was scored high severity, which in this pipeline carries a heavy score penalty and can force an outright failure. A draft could be well written, coherent and complete and still score zero, because the validator had manufactured a structural defect and then punished the article for it.

The second is that the correct value already existed in the same codebase. src/autofix.ts:34 sets its own content budget to 24,000 characters, operating on the same drafts in the same pipeline. The rewrite step could see three times more of an article than the step deciding whether the article was any good.

The fix

Commit aa3724e raised the validator's budget to 24,000 characters, matching the value already in use six files away, and applied it to both call sites.

The measurable effect: across the estate, 12 drafts exceeded 8,000 characters and 10 of them were marked failed. Re-running validation on the worst example after the change moved it from a failed verdict scoring zero to a passing verdict scoring 0.654, with coherence at 0.92 and voice at 0.88. Both high-severity issues disappeared, because neither was ever real.

The problem was detected on 2026-07-27 and fixed on 2026-07-30.

Why it happened

Two limits on the same content in the same pipeline, defined independently, in two files, by two people solving two problems. Neither is wrong on its own. The validator's author was bounding the cost of a model call. The rewriter's author was making sure a revision could see the whole article. Nobody wrote down that these were the same constraint.

Underneath that is a subtler failure. The validator reported a symptom it had caused, in language confident enough that nobody checked. It did not say the content was truncated for review. It said the article cuts off mid-sentence, quoted the evidence, and named the consequence. Every part of that was true about the input it received, and false about the article.

A checking system that can corrupt its own input will produce findings that are locally correct and globally wrong, and it will produce them in exactly the register that discourages questioning.

How to avoid it

Three things generalise.

If two components process the same object, their limits belong in one place. Duplicated constants drift silently, and the drift shows up as behaviour nobody can explain rather than as an error.

When a quality check reports a problem, verify the problem exists in the source before acting on the report. The failure here was not that the tool was wrong. It was that the tool's output was treated as an observation about the article when it was an observation about a slice of the article.

Be suspicious of any defect whose severity scales with the size of the input. That shape rarely indicates a content problem. It usually means something in the path is bounded, and the boundary is being crossed by exactly the inputs that matter most. In this case the articles most likely to fail were the longest and most thorough ones, which is the precise opposite of what the check existed to achieve.

Every commit, file reference and date above is checked against this incident's evidence record before publication. Evidence: editor-judge-8k-truncation.