Separate a project's facts, risks and predictions with AI
The notes say the release is expected on 15 October if approval comes through. By the third rewrite, the update says it's confirmed. A forecast can become a fact during a fluent rewrite.
What you'll make
a short map of the claims in your project notes, each labelled with its exact wording, and an update that keeps reported events, pending items, risks and forecasts apart.
What you'll need
the current project notes (pasted or uploaded), with dates and any records you have, in a chat your organisation lets you use for them: ChatGPT, Claude, Microsoft 365 Copilot Chat or Gemini. Allow about 10 minutes.
Example result.
| Claim, as written | Label |
|---|---|
| “Staging demo completed” (2 October) | Reported event |
| “Production approval still pending” | Pending |
| “Late source file may delay the backfill” | Risk |
| “Rollout expected 15 October if approval and backfill check pass” | Forecast, conditional |
Update: Staging demo reported complete on 2 October. Production approval is pending. Rollout is proposed for 15 October if approval and the backfill check pass; a late source file could delay it.
1. Ask for labels tied to the exact words
Sprint reviews and roadmap updates mix all four kinds of claim. “Passed on staging” is a report; “could delay the launch” is a risk; “ready next sprint” is a prediction. Ask the model to label each one with the words it came from:
Map the claims in these project notes. For each, quote the exact
wording, give the source and date if there is one, and label it as
reported event, pending, risk, forecast or unclear. Keep conditions
attached to the claim they belong to. Don't turn an expected date into
a commitment, or a plan into something that happened. Then write a
short update using the same labels: [notes].[notes] is the project notes, pasted or attached.
A note that reports something happened isn’t the same as proof it happened. Label it “reported” unless you have the record, such as the test result or the approval email.
Why this works: quoting the words makes each label checkable. A label without its source sentence is just another confident summary.
What you should see: a table like the example result, and an update that uses its labels.
2. Split sentences that mix states
One sentence can hold a report and a forecast: “Staging went well, so we’re on track for the 15th.” Ask the model to separate them:
Find any statement that mixes something completed, something pending
and something predicted. Split it without changing its meaning. For
each unclear or unsupported claim, name the record or answer that would
settle it. Don't add a confidence percentage.Why this works: “on track” hides the difference between what happened and what’s hoped for. Splitting the sentence shows which part needs a record.
What you should see: mixed sentences split into labelled parts, and a short list of records to ask for, such as “approval email from the release manager”.
3. Check the words, then the visuals
Read the update against the notes. Check every date, every “if”, and every verb: “completed”, “confirmed”, “approved” and “live” need a source that says so. Then check anything visual made from it. A timeline that puts every item on one green delivery line says “done” whatever the text says.
Why this works: forecasts usually turn into facts through one changed verb or one dropped “if”.
What you should see: an update where every “if” and “pending” from the notes survives.
Check the result
- Every claim in the update matches the label and wording in the map.
- Conditions such as “if approval passes” are still attached to their dates.
- Nothing is called confirmed, approved or live unless a note or record says so.
- Unclear dates such as “next week” are flagged, not turned into a calendar date.
The usual failure: the update promotes a forecast to a fact. “Rollout expected 15 October if approval passes” becomes “Release confirmed for 15 October”. Spot it by checking each date against its “if” in the notes. Repair it:
The update says [overstated claim]. Source [ID] only says [what the note
says]. Restore the right status and any condition on the date. Check
the headline and any timeline labels too. Don't invent an approval or
test result to close the gap.Worked example: a conditional rollout
Fictional example. A data team’s notes for a reporting-pipeline change:
S1 (2 Oct): Staging demo completed. Sample rows matched.
S2 (3 Oct): Production approval still pending with the release manager.
S3 (3 Oct): Rollout expected 15 October if approval and backfill check pass.
S4 (4 Oct): Late source file may delay the backfill.The first AI update read:
Weak: “Staging passed and release is confirmed for 15 October. The backfill is on track.”
- Two forecasts became facts. “Confirmed” has no source; S3 says “expected … if”. “On track” contradicts the risk in S4.
- “Passed” quietly widened S1. The note says a demo completed and sample rows matched, not that staging passed every check. The map labels it “reported event”.
- The repair restored the conditions. The repair prompt with “Release is confirmed for 15 October” and “S3 says rollout expected 15 October if approval and backfill check pass” produced the update in the example result.
Task kit for this job: Download (ZIP) · Reusable instructions
Go deeper
Keep vague dates vague
If a note says “next week” with no date written, don’t let the model turn it into a calendar date. Today’s date isn’t necessarily when the note was written. Ask the author, or keep “next week (from a note dated 3 October)”.
Tailor the update without changing the status
An executive summary can lead with the decision and an engineering note can explain the check, but both keep the same “pending” and the same “if”. The three-reader technical update guide shows how.
Link each headline to its source
Give each sentence in the update the note it came from, so a reader can check it in seconds. A link only helps if the note supports the exact words. The executive summary source trail guide develops the check.