Worked example: rewrite weak notes

The first prompt says only, “Summarize this meeting and list actions.” It produces:

The team agreed to proceed with the 20 June mobile checkout launch. Engineering will fix stability issues and deliver a build. Payments approved the library change. Support will prepare documentation, with Product providing screenshots. Everyone was positive about the plan, and final details will be confirmed Monday.

Actions: Luis—finish engineering work; Mei—support payments; Arun—write docs; Dana—provide screenshots.

The output is fluent and wrong in several ways. It promotes “leaning toward” into approval. It says Payments approved a change that Mei explicitly had not reviewed. It invents a positive group mood. It changes Dana’s task from reviewing screenshots to providing them. It drops dates, conditions, the stability threshold, and the inaudible segment. “Support payments” is not an executable action.

Before rewriting, define the required sections:

• current launch status;
• verified facts and thresholds;
• decisions and non-decisions;
• actions with owner, deliverable, and due date;
• dependencies and open questions;
• risks and source uncertainty.

The audience is the delivery team and an absent launch sponsor. Therefore, the notes need enough rationale to explain why no final decision was made, but they do not need every conversational turn.

Create candidate records before writing prose:

Fact: Crash-free sessions measured 99.3% yesterday. Source: Luis at 10:02.

Criterion: Dana proposed 99.5% as a condition for retaining 20 June. Source: 09:14. Status: proposed criterion; not explicitly approved by the decision-maker in the excerpt.

Non-decision: Team is leaning toward 20 June, but no launch decision should be recorded before the build passes. Source: Dana at 16:20.

Dependency: New build depends on Payments approving the library change. Sources: Luis at 10:02 and Mei at 12:41.

Source gap: Test-device discussion at 14:33–15:10 is inaudible. Impact: any conclusion based on that segment requires attendee confirmation.

This extraction prevents the rewrite from treating every statement equally. It also reveals that “99.5%” may be an important criterion without evidence that the whole group adopted it.

Only one clear process decision appears: the final go/no-go decision will occur at Monday’s launch check after the build result. The 20 June date remains a candidate, not an approved launch.

The actions become:

• Mei: review the proposed payments-library change and respond by Wednesday afternoon. Dependency: Engineering must send the change today.
• Luis: provide a new mobile build on Thursday, assuming the library change is approved.
• Arun: draft the troubleshooting article at least two business days before any launch. Missing: exact delivery date until launch is approved.
• Dana: review Arun’s screenshots on Friday.

There is also an implied action—someone must send Mei the change today—but the owner is not explicit in the quoted source. Do not assign it to Luis merely because he discussed the build. Record “owner unconfirmed” and ask the chair.

Status

No final launch decision was made. The team is considering 20 June and will make the go/no-go decision at Monday’s launch check after reviewing the new build.

Evidence and conditions

• Crash-free sessions measured 99.3% on the previous day.
• Dana suggested maintaining at least 99.5% as a condition for the 20 June launch; confirm whether this is the approved threshold.
• The new build depends on Payments approving the proposed library change.
• Part of the test-device discussion was inaudible from 14:33 to 15:10; confirm any resulting requirement with attendees.

Actions

• Mei will review the library change and respond by Wednesday afternoon, after receiving it.
• Luis will provide a new build Thursday if the library change is approved.
• Arun will draft the troubleshooting article at least two business days before launch; exact due date follows the go/no-go decision.
• Dana will review the support-article screenshots Friday.
• Unassigned: send the library change to Mei today. Dana will confirm the owner after the meeting.

Next decision

Monday launch check: decide go/no-go for 20 June using build stability, payments approval, and readiness of support materials.

Now verify each high-impact field against the source:

• 20 June: candidate date, not a decision.
• 99.3% and 99.5%: preserve the decimal and distinguish measurement from threshold.
• Wednesday, Thursday, Friday, Monday: confirm actual calendar dates before publishing; relative dates become ambiguous later.
• Mei’s status: review promised, approval not yet given.
• Dana’s task: review screenshots, not create them.
• Missing owner: leave visible until confirmed.

Ask attendees to clarify the inaudible device discussion and the approved stability criterion. If nobody can verify them, retain the uncertainty rather than completing the story.

The strongest improvement is not better wording. It is status discipline. The rewrite distinguishes a candidate date from a decision, a dependency from an approval, and an implied task from an accepted assignment. It preserves a source gap and turns relative timing into a verification item.

AI can accelerate extraction and formatting, but the reviewer supplies accountability. A model cannot decide that a proposed threshold has organizational authority or that an unspoken owner accepted a task.