The verification loop

Loop two is small: something produces work, something else grades it, and a failure comes back as a critique for the next attempt. The mechanism takes an afternoon. Getting value from it depends on details that look cosmetic and are not.

The first is that the checker must be a separate call. A model reviewing its own draft in the same conversation is anchored on the reasoning that produced it — it reliably catches omissions and reliably misses its own misconceptions. Fresh context is what makes the check worth running.

The second is that a different model is usually better than the same one twice. Different training produces different blind spots, and the whole point of a checker is to have blind spots that do not overlap with the maker's.

The third is what comes back. A verdict alone gives the maker nothing to act on: told only that it failed, a model will usually produce a near-identical draft. The critique has to say what to change.

attempt 1  "...a refund will be with you shortly."
  checker   FAIL - includes a timeframe, which the rubric forbids
  fed back  remove the timeframe; say someone will be in touch

attempt 2  "...someone will be in touch to discuss next steps."
  checker   PASS

One failure mode is worth designing against explicitly: a checker whose output you cannot parse. It is tempting to treat that as a failure and retry. Do not. An unreadable checker has not checked anything, and feeding an empty critique forward produces a loop that burns its whole budget rewriting the same draft. Stop instead, and say which model to replace.