5.5 Iterate: change the part that failed

In everyday life. A recipe came out too salty. You cut the salt next time, not every ingredient.

To iterate is to improve a brief round by round. Read the first result as a test of your brief. Find its biggest problem, then ask whether your brief covered it. Say the worker used policy version 2, and your brief never named a version. That is a gap in the inputs. The table shows which part to change for each kind of problem.

What you see	The part to change	For example, add
It made the wrong thing, or too much of it	Outcome	"Pay covers invoices due on or before October 30."
The content is right, but the shape or the destination is wrong	Format	"A proposal CSV, one row per open invoice."
A wrong fact, an old rule, or a source it should not have used	Inputs	"Use AP policy version 3 for every rule."
It decided something it should have asked about, or kept asking about small things	Autonomy	"List for Dave anything the policy does not cover."

Change that one part, run the brief again, and compare the two results. Changing everything at once hides what worked.¹ If the brief is good and the work is still weak, the brief is not the problem. Try a stronger model, if your app lets you choose one, or split the work into smaller stages. Chapter 11 shows how to find the cause of failed runs.

Save your brief as a file, so you can reuse it. Then write each lesson into the saved brief. Maria's next version of the brief says "terms from the vendor record" because the last run taught her that. Stop iterating when another round changes little and finishing by hand would be faster.

5.5 Iterate: change the part that failed

Check yourself

A result used policy v2, and your brief never said which version wins. Which part do you change?

Sources