Chapter BIterate: bad to betterPage 6 of 8

Iterate: bad to better

Worked example: a revision ladder

A visible revision trail shows how diagnosis, one-change feedback, and verification turn vague output into usable work.

~15 minWorked example

Before you start

Why this matters

Consider fictional notes from a small project:

  • Pilot scheduled for 12 August.
  • Accessibility review found two keyboard-navigation blockers.
  • Ren will retest after fixes; no date agreed.
  • Team discussed delaying the pilot but made no decision.
  • Jo will ask the customer group about availability by Friday.

The task is to draft a concise status message for a manager. It must state status, separate decisions from proposals, preserve owners, and avoid invented dates.

1Learn the idea

Read

Round 1: the vague request

Prompt: “Write a professional update from these notes.”

The draft says: “The pilot remains on track for 12 August. The team will complete accessibility fixes, and Ren will retest them next week. Jo is coordinating with customers. We are confident the pilot will proceed as planned.”

Diagnosis: the prose is smooth, but it converts the scheduled date into “on track,” invents Ren’s timing, and turns an undecided delay into confidence. This is primarily an evidence and uncertainty failure, not a tone failure.

Read

Round 2: control the facts

Revision instruction:

Use only the notes. Separate confirmed facts, proposals, and unknowns. Do not infer dates or confidence. Preserve names exactly. Keep everything else concise.

The result now says:

“The pilot is scheduled for 12 August. Accessibility review identified two keyboard-navigation blockers. Ren will retest after fixes; the retest date is TBD. The team discussed a delay but has not decided. Jo will confirm customer-group availability by Friday.”

This passes the evidence gate. However, the manager still cannot quickly see what requires attention. The next diagnosis is usability: correct facts are presented as one flat paragraph.

Read

Round 3: expose the decision

Revision instruction:

Preserve every fact and uncertainty from V2. Reformat as Status, Decision needed, and Actions. Put the unresolved pilot-date decision first. Do not add recommendations.

The result:

Status: Two keyboard-navigation blockers were found. The pilot is scheduled for 12 August.

Decision needed: Decide whether the blockers require moving the pilot date. No delay has been approved.

Actions: Ren—retest after fixes; due date TBD. Jo—confirm customer-group availability by Friday.”

The structure improves scanability and keeps evidence stable. Yet “decide whether the blockers require moving the pilot date” is a reasonable framing rather than an explicit statement from the notes. It should not be presented as a formally assigned decision without checking. The output can say “Question to resolve” instead.

Read

Round 4: calibrate attribution

Revision instruction:

Change only the heading and wording that imply a formally assigned decision. Label it an open question derived from the discussion. Keep the rest unchanged.

The revised section reads: “Open question: The team discussed whether the accessibility blockers could require moving the 12 August pilot, but made no decision.”

This is more faithful. The final review checks every date and owner against the notes, confirms that “two” and “keyboard-navigation” remain exact, and verifies that no confidence claim reappeared.

Read

Score the ladder

Using accuracy, completeness, scanability, attribution, and tone on a 0–2 scale:

  • V1 may score well on tone but fails the accuracy gate.
  • V2 passes accuracy and completeness but is only partly scannable.
  • V3 improves structure but overstates the status of a decision.
  • V4 passes the hard gates and balances all five criteria.

The latest version wins here, but only because each revision was checked. The exercise also shows that model output can introduce a subtle new problem while fixing an older one.

Read

Turn the lesson into a template

A reusable prompt for similar updates could include:

Using only the notes, produce Status, Open questions, and Actions. Preserve dates and names. For each action, show owner and due date; use TBD when absent. Do not turn discussion into a decision or a scheduled date into a confidence claim. Keep under 140 words.

Test that template on notes with a confirmed decision, no actions, conflicting dates, and irrelevant side comments. Examples that differ from the original case reveal whether the rule generalizes.

Checking tutor…

Continue learning · glossary & guides