Plenty of product copy has to hit a number: a reading level, a word count, a tone score, a character budget. The usual build is to write the number into the prompt and trust the model. Across four commercial models that landed inside the target band 21.1% to 31.6% of the time. Wrap the same models in an ordinary control loop instead — generate, score the draft in code, hand back one diagnosed edit, re-score, stop when it lands — and the hit rate goes to 92.5%–98.8% in 1.7 edit rounds. The model never judges whether it met the constraint. It only writes.
The baseline is the thing almost everyone ships: one prompt, one draft, the target written into the instruction. Three models wrote 38 passages each — four topics, five difficulty levels, two word counts — and a script checked afterwards whether the text actually landed inside the requested reading-level band. Most of it did not, and nothing in the system knew.
Pick a model, then slide how many drafts you are willing to throw away.
Two things are worth separating here. The models are not bad writers — the passages were fine. They are bad estimators of a statistic computed over their own output, and no amount of prompt phrasing fixes an estimator. The second is that a miss is silent: without a checker, a draft that came out three grades too hard is indistinguishable from one that landed.
The whole architecture rests on one property of the constraint: it is computable without a model. The paper's target is a grade-family mean — the average of four classic readability formulas (Flesch–Kincaid Grade, the Automated Readability Index, Coleman–Liau and Gunning Fog) — and five difficulty levels map onto bands of the US grade scale. A passage hits if the mean falls inside the band; length has to land inside [0.9×, 1.2×] of the requested word count.
All four formulas read the same two or three surface features. Move them and watch the mean walk up and down the scale.
Notice how far apart the four formulas sit on the same text. Gunning Fog punishes long words hard; Coleman–Liau barely reacts to them. Averaging them is not a truth claim about reading difficulty — it is a choice of controlled variable, and the authors are explicit that hitting it proves the metric is controllable, not that a human found the text easier. That honesty is the right way to read the rest of the paper: this is control engineering, not a reading study.
The architecture is deliberately boring, which is the point: it is a controller from any other engineering discipline, with a language model dropped into the one slot that needs language. Deterministic code decides whether the draft is acceptable and what is wrong with it. The model receives a diagnosis and performs an edit. Nothing asks the model to grade itself.
Step through the stages.
One detail in generate is worth stealing on its own. The models systematically under-produce length, and worse at the easy levels, where short sentences make the word budget run out early — so the generator multiplies the requested count by a level-specific factor, from 1.40 at the easiest level down to 1.00 at the hardest. That is a feed-forward correction for a known bias, sitting in front of the feedback loop. Measure your own model's bias once and you get the same cheap win.
Now the loop itself. Drop a first draft anywhere on the scale and watch the controller walk it into the band. The editor that may only swap words moves in smaller steps than the one allowed to restructure sentences.
In the paper's 240 runs the loop needed 1.68 to 1.78 rounds on average against a cap of five, which is the detail that makes this shippable: the deterministic half does most of the work, so you are not paying for a long resampling tail. And the comparison against asking nicely is not close.
A loop that optimises a readability score will happily delete the hard parts of a passage, and it would score beautifully doing it. So every proposed edit passes a content-validation gate before it is accepted: a weighted recall score over what the source text contained, with entities weighted highest, then numbers, then keywords.
Set what an edit kept and see whether it survives. The threshold rises to 0.85 for edits that only claim to change wording or sentence structure — those have no excuse for losing anything.
Across the 240 runs the accepted edits averaged 0.92–0.93 fidelity against a 0.72 bar, so the gate was rarely the binding constraint — it was doing what a guard should do, which is nothing, loudly, when it matters. But read the mechanism before you copy it: recall only means the gate checks that source entities, numbers and keywords are still present. It cannot see an altered one.
The authors say this plainly, and it generalises to every recall-style guard people bolt onto rewriting pipelines. If the text carries claims, the loop needs a second gate that compares values and polarity, not just presence.
Generalise past readability. Anything you can compute from the output without a model is a candidate: word and character budgets for a notification, a required JSON shape, a banned-phrase list, a citation count, a tone classifier you already run, the number of bullet points in a summary. The pattern is identical — put the check in code, let the model write and edit, count the rounds.
The price is extra calls. The paper's loop averaged 1.74 edit rounds on top of the first generation, so budget roughly 2.7× the calls per accepted item. Set your own volume and your own measured hit rate.
The trade is usually easy, because the two sides are not the same kind of cost. The extra calls are a line item you can forecast. The off-spec items are a support ticket, a compliance finding, or a notification that got truncated by the channel it was sent to — and without a checker in the path, you find out about them from a user.