One of the pipelines we run translates articles from English to Ukrainian. It has six stages: fetch, categorize, translate, review, polish, publish. The review stage scores each translation from 0 to 10. Anything at 8 or above goes straight to publishing. Anything below gets a polish pass, where a dedicated agent reads the reviewer’s feedback and revises the translation, and then the result goes back to review.
That loop could run forever. We cap it at two iterations. If a translation has been polished twice and still scores below 8, we publish it anyway, flagged with a warning status so a human can find it later.
The first time we describe this to someone, the reaction is usually the same: why would a quality gate have an escape hatch? If 8 is the bar, publishing a 7.5 looks like giving up. It took us a while to articulate why the cap is not a weakness in the design. It is the design.
Revision loops don’t converge, they oscillate
The mental model behind an uncapped loop is that each pass moves the score monotonically upward: 6.5, then 7.4, then 8.1, done. Some articles do behave that way. The first polish pass usually captures most of the available gain, because the reviewer’s first round of feedback contains the real problems: a mistranslated idiom, inconsistent terminology, a paragraph where the sentence structure is still visibly English underneath.
The second pass captures less, because the feedback it works from is what remained after the big problems were fixed. And somewhere around there, a different thing starts happening. The score stops climbing and starts wandering.
A review score is a measurement, and measurements have noise. Two honest reviews of the same text can land half a point apart, because judgment about phrasing is not deterministic. When a translation sits near the threshold, the loop stops responding to quality and starts responding to noise. We watched an article go 7.8, then 8.0 would have released it, but it drew a 7.7, got polished a third time in an early uncapped version of the pipeline, and came back at 7.8 again. The text was changing. The quality was not.
Past a certain point, a revision loop is no longer improving the artifact. It is resampling the reviewer.
Once we saw that pattern, the cap stopped looking like a budget constraint and started looking like a correctness fix. An uncapped loop treats the score as ground truth. A capped loop treats it as evidence.
The cap changes the failure mode from stall to signal
Without a cap, an article that can’t reach the bar becomes a stall. It sits in the loop, consuming a polish pass and a review pass per cycle, and everything behind it in the queue waits. The pipeline’s throughput is now governed by its most stubborn item, which is a bad property for a system that is supposed to run unattended.
With a cap, the same article becomes a signal. It ships with a warning flag, the queue keeps moving, and the flag accumulates somewhere a person actually looks. The flag does not mean “we decided this is fine.” It means “the automated process got this as far as it could, and here is exactly where it stopped.”
This distinction matters more than it seems. A pipeline that blocks on imperfection quietly converts quality problems into availability problems, and availability problems are worse, because they are invisible from the outside. Nobody reading the site knows an article is stuck in a loop. They just see that nothing new was published this week. A flagged article at 7.6 is a known, bounded, inspectable defect. A stalled queue is an outage.
Why two, and not three
The specific number came from watching what the feedback looked like at each iteration, not from a cost spreadsheet.
First-pass feedback is concrete: this term is wrong, this sentence lost a negation, this heading should follow the site’s conventions. Second-pass feedback is thinner but still actionable, mostly leftovers from the first round. By the third pass, the feedback is largely restatement. The reviewer, having nothing structural left to object to, starts expressing preferences, and the polisher, having nothing concrete to fix, starts rephrasing things that were already acceptable. The loop is doing work, but it is not doing the work the loop was built for.
There is also a diagnostic angle we did not anticipate. Articles that hit the cap cluster. They are not randomly distributed across the queue; they share causes. Dense theological source texts with terminology our glossary does not cover yet. Articles built around wordplay that has no Ukrainian equivalent. Long quotations from older translations that resist modernization. When an article exhausts its two passes, the problem is almost never that the polisher needed a third attempt. It is that something upstream, usually the glossary or the source selection, needs attention that no amount of downstream revision can substitute for.
An uncapped loop would have hidden that from us. It would have eventually brute-forced some of those articles over the line, or oscillated on them indefinitely, and either way the upstream gap would have stayed invisible. The cap surfaces it as a pattern we can act on.
Thresholds are routing decisions, not verdicts
The threshold of 8 looks like a statement about quality, but in practice it is a statement about routing: which path does this artifact take next. Above the bar, the fast path. Below it, one more round of attention. At the cap, a different path entirely, one that includes a human.
Framing it that way dissolved most of our discomfort with publishing below the bar. We are not asserting that a 7.6 is secretly an 8. We are asserting that the next unit of improvement for that article will not come from another loop iteration, and the system should route it accordingly.
We suspect this shape generalizes beyond translation. Any pipeline with a generate-evaluate-revise loop has to decide what happens when the loop does not converge, and pretending it always converges is not a decision, it is a deferred incident. The honest version of the question is not “how do we make every item pass the gate” but “what does the system do with the items that won’t, and who finds out.”
For us, the answer is: two passes, a flag, and a queue that keeps moving.