A long text edited in pieces
The document is split on paragraph boundaries, each piece is edited on its own, and it is glued back in order.
What the scenario looks like
- Execute + Data
- LLM
It is not about the model’s limit: it will accept a long text. It is about quality — the beginning gets edited carefully and by the end things start slipping through. In pieces, the whole text is edited alike.
What is inside
- A long text — the entry.
- Split into pieces — a code node. It cuts on paragraph boundaries, filling pieces of roughly three thousand characters: a break mid-sentence ruins both the edit and the join.
- For each piece — the loop, whose body edits one fragment.
- Glue reassembles the results in the same order.
Piece length comes out approximate, and that is the right trade: keeping a paragraph whole matters more than an even size.
One thing here breaks more quietly than anything else: the loop’s item reaches the model node
on its Message port, not “Input”, and its prompt says {{ inputs.message }}. Write
inputs.input and the prompt goes out empty, the model dutifully answers nothing, the loop
collects a list of blanks — and the run stays green.
What to set up for yourself
- The piece size — a constant on the first line of the code. Smaller means a more careful edit and more calls.
- The editing prompt. It is copy-editing today: strip officialese, break up long sentences, keep the facts. The same graph does translation, simplification or markup.
- The join. Pieces are separated by a blank line. If the edit changes structure, headings belong between them.
What to connect
Nothing. There will be one call per piece: a page of text is one or two, a twenty-page contract is twenty, and the run time grows with them.