When the aim and the floor are the same number, the model treats the floor as the target and writes to it. That is the whole finding. The rest of this note is the evidence, the mechanism and the four-knob fix.
What the Pipeline Looked Like Before
The article pipeline for an electrical contractor client used a single instruction in the Generate Article prompt: aim for 1,400 to 1,800 words, never under 1,400.
The lower bound of the range and the never-under figure were identical. There was no separate expansion pass, no distinct throw floor and no ceiling stated anywhere else in the flow.
What the Published Guides Actually Showed
The commit on 2026-09-16 documents body word counts for ten published guides. The picture is not pretty:
- Lowest count: 1,203 words, which is three words over what became the 1,200 throw floor.
- Four guides landed within 100 words of that floor.
- One execution wrote 1,005 words and killed the run entirely, because the pipeline had no expansion pass to catch it.
That last one is the clearest signal. The model did not just cluster near the floor, it fell through it. A prompt that says "never under 1,400" did not prevent a 1,005-word draft. It just meant the run died with nothing published.
Why the Model Clusters at the Floor
The model reads a range like 1,400 to 1,800 and treats the lower bound as the satisficing point. Writing 1,400 words satisfies the constraint. Writing 1,800 words also satisfies it, but requires more tokens and more decisions about what to include.
Without an upward pull, the model gravitates toward the minimum. This is not a bug in the model. It is a predictable consequence of how the constraint is framed.
The same logic applies to the never-under phrasing. It sets a floor but gives the model no reason to aim above it.
The False Threat Making Things Worse
The old prompt also contained a line claiming that a short draft "is rejected by the system and wastes the run." That was not true. At the time the line was written, there was no expansion loop. By the time the commit landed, there was. The line was stale and factually wrong.
A false threat like that does one of two things. Either the model ignores it, in which case it does nothing. Or the model responds to it by padding, adding filler sentences to hit the number without adding substance. Neither outcome is good.
Removing the line is a separate change from fixing the length knobs. It is worth keeping them separate in your own head, because conflating them makes it impossible to know which change did the work.
The Four-Knob Fix
The commit introduces a document, docs/runbooks/article-length-rule.md, that defines four distinct values and where each one lives in the pipeline:
- 1,650 aim: sits in the Generate Article prompt. This is the number the model is told to write toward. It is not a floor and not a ceiling.
- 1,400 expansion threshold: sits in the Too Short? IF node. If the draft comes in below 1,400, the pipeline sends it through one expansion pass asking for more detail. One pass only.
- 1,200 throw floor: sits in Compose Draft. If the draft is still below 1,200 after the expansion pass, the run aborts. Nothing gets published.
- 2,000 hard ceiling: also in the prompt. Drafts above this are trimmed or flagged depending on how far over they go.
The gap between the aim (1,650) and the throw floor (1,200) is 450 words. Normal model variance on a guide-length article is well inside that gap, so a draft that falls a bit short of the aim still has room to clear the floor without needing the expansion pass.
The expansion threshold at 1,400 sits between them as a catch. A draft that lands between 1,200 and 1,400 gets one more attempt before the pipeline decides whether to abort.
Verifying the Live Prompt
One thing worth noting from the commit: the verification step included a live readback of the n8n prompt node inside the running workflow. Not the file on disk. Not the version in source control. The actual prompt the workflow was executing.
This matters because n8n workflows can drift from what you think you deployed. If you fix the prompt in your editor and forget to save it back into the workflow, the pipeline keeps running the old version. The live readback is the only way to be certain.
What the Commit Does Not Claim
The commit does not include a post-fix word-count distribution. There is no table showing that the new prompt produces guides averaging 1,650 words. That data does not exist yet, because the change was made on 2026-09-16 and the guides take time to accumulate.
It would be easy to write a sentence here claiming the fix worked. It would also be invented. The honest position is: the mechanism is sound, the old prompt was provably broken, and the new one should perform better. Whether it does is a question for a future commit.
What I'd do differently
- Instrument word counts from the start. Ten guides published before anyone noticed the clustering. A simple log of body word count per run would have flagged it after two or three.
- Separate the knobs before the first deployment. The four-knob structure is not complicated. It just requires thinking about aim, expansion, floor and ceiling as distinct concerns rather than collapsing them into one range.
- Audit prompt claims for accuracy. The false threat about wasting the run was in the prompt for long enough to affect published content. A prompt is a specification. Stale specs cause bugs the same way stale code does.
- Keep the expansion pass to one attempt. The current setup does this correctly. More than one expansion pass risks a loop that inflates the article with padding rather than substance, which is exactly the behaviour the false threat was accidentally encouraging.