Module · M4 · The control layer
The bounded correction loop, capped at 3
Lesson 16 of 21 · 9 min
A rejection should not end the run. Most rejected proposals are nearly right, and the reviewer has just written down exactly what is wrong with this one. Feeding that critique back is the cheapest quality improvement in the whole architecture.
The pattern, before any nodes: propose → judge → carry the critique back → try again → cap the attempts. The cap is not an optimisation. It is the difference between a system that corrects itself and one that argues with itself at your expense.
You cannot draw the arrow backwards
The obvious construction is an edge from the reviewer back to the proposer. The validator rejects it: a canvas may not contain a cycle. This is a good constraint — an unbounded loop between two model calls is a bill with no upper limit — and the product’s answer is a purpose-built node.
The loop, in count mode
The proposer and reviewer sit inside the loop body. Flow continues from the loop's completion handle to the gate.
Scroll for all 12 steps →
Read the break condition: the loop stops as soon as the parsed verdict says approve. It does not run three times and take the best one — it runs until it is right, at most three times, and on the verified run it broke early after the second attempt.
What the loop actually produced
| Attempt | The proposal | The verdict |
|---|---|---|
| 1 | a cash refund, auto-approved | rejected, 2/5 — three violations named verbatim |
| 2 | cash refund denied; deadline extension, platform credits, at most one free seat, and an escalation | approved, 5/5 — “correctly denies a cash refund, offers compensation in line with policy” |
1
- The proposal
- a cash refund, auto-approved
- The verdict
- rejected, 2/5 — three violations named verbatim
2
- The proposal
- cash refund denied; deadline extension, platform credits, at most one free seat, and an escalation
- The verdict
- approved, 5/5 — “correctly denies a cash refund, offers compensation in line with policy”
Carry the critique, not the whole conversation. The proposer reads the previous critique as one field in its context, and is told that a critique present means this is a revision. It is not re-sent its own earlier proposal. Feeding the full transcript back makes the second attempt defend the first one instead of replacing it.
What happens on the third failure is your decision
The loop cap is a policy question wearing a technical costume, and the product cannot answer it for you. Three attempts fail — then what?
- Escalate to a human with the last proposal and every critique attached. That is what this build does, and it is the right default for anything involving money.
- Fail silently and drop the ticket. Almost never right, and always what happens by accident when nobody chooses.
- Take the best-scoring attempt anyway. Defensible for low-stakes work, indefensible here — the reviewer rejected all three for reasons it wrote down.
One builder-level gotcha, so a red badge does not greet you. In count mode the loop still requires an output field name to be set, and must not carry the array fields used by the other mode. The workflow validator passes either way; the canvas shows an issue only in the builder. Set the output field, leave the array fields empty.