Status reports and unknowns: writing the evidence-based status update

By the end, you can

• Define a status report and distinguish it from a progress report, and explain what makes a status update "evidence-based" rather than a general impression (PM-3).
• Critique an AI-drafted status report for stating an interpretation, an unconfirmed assumption or an unresolved risk as settled fact (PM-3).
• Assemble meeting notes, an action log and clearly labelled unknowns into one evidence-based status update (PM-3).

Before you start

This is Module 4, Lesson 3 of the AI-Powered Project Management course, and the last lesson before Module 5's work on governance and review. It builds on Lesson 1's fact/interpretation/decision/unknown record and Lesson 2's action log, and closes this module by assembling both, plus honestly labelled unknowns, into one document: an evidence-based status update.

A status report and a progress report are not quite the same report

Project work produces more than one kind of regular update, and the two easiest to blur are a status report and a progress report. APM's project management glossary defines a status report as "a description of where the project currently stands, usually in the form of a written report, issued to both the project team and other responsible people on a regular basis, stating the status of an activity, work package or whole project," adding that "it may be a formal report on the input, issues and actions resulting from a status meeting." A status report is close to the ground: frequent, operational, and often tied directly to a status meeting like the ones Lessons 1 and 2 have been building records for.

The glossary defines a progress report separately, as "a regular report to senior personnel, sponsors or stakeholders summarising the progress of a project including key events, milestones, costs and other issues." A progress report is written for people further from the day-to-day work, at a level of summary they can act on without reading every detail. This lesson focuses on the status report — the working artifact closest to what Lessons 1 and 2 have already built — though the same evidence discipline applies just as much when that material later gets summarised upward into a progress report.

What makes a status update evidence-based

A status update that says "the kitchen extension is on track" is either useful or misleading, and nothing in that sentence alone tells you which. An evidence-based status update is one where every claim in it points back to something checkable: a fact confirmed in Lesson 1's meeting notes, a decision actually recorded, an action-log entry showing what's done and what's still open, or an unknown honestly named as still unresolved. "On track" backed by "steel delivery delayed five days, builder has confirmed a four-day schedule impact, revised completion date agreed with the client" is a claim a reader can check. "On track" on its own is a feeling.

Unknowns deserve the same explicit treatment as facts, not silence. A status update that quietly omits an unresolved risk because nobody has a confident answer yet isn't more reassuring than one that names it — it's just less honest, and it leaves the reader unable to ask the one question that might actually matter. Naming an unknown plainly — "the cause of the delivery delay is not yet confirmed by the supplier" — costs a sentence and preserves the reader's ability to judge the situation for themselves.

AI can draft the report; the named owner checks what it quietly turned into fact

Given a set of meeting notes and an action log, an AI assistant can draft a genuinely readable status update: a short narrative pulling the week's facts, decisions and open actions into a few paragraphs someone can read in a minute. That is useful work — turning several sources into one coherent update takes real effort by hand.

It is not the same as an update that has actually been checked for what it quietly promoted from guess to fact. The Open Worldwide Application Security Project's (OWASP) guidance on misinformation warns that "overreliance occurs when users place excessive trust in LLM-generated content, failing to verify its accuracy" — and a status report is exactly the kind of document where that risk compounds, because it's the artifact most likely to travel furthest, to the people least able to check it themselves. A draft can turn a hedge like "the builder expects to make up most of the time" into a flat "the schedule impact has been absorbed," simply because a confident sentence reads better than an uncertain one. The US National Institute of Standards and Technology's (NIST) AI Risk Management Framework's description of an AI system as something that "can, for a given set of objectives, generate outputs such as predictions, recommendations, or decisions" is exactly why that confident-sounding line is a draft to check, not a verified state of the project.

Approving a status update before it goes to people who will make decisions based on it — a client, a sponsor, a stakeholder who isn't in the room — is itself the kind of call OWASP's guidance on excessive agency has in mind when it recommends that a human "approve high-impact actions before they are taken." Once a status update is sent, its reader has no way to tell which lines were checked and which weren't; that check belongs with the named project lead, not with the draft that first wrote it up.

Assembling the evidence-based status update

An evidence-based status update is not a new invention — it is what this module has been building one element at a time. It draws on three things, and an update missing any one of them is closer to an impression than a report:

AI can draft a first pass pulling all three together, the way this module's earlier lessons have shown. What makes the result an evidence-based status update, rather than a confident-sounding summary, is the same discipline this course has applied to every earlier artifact: the named project lead checks each claim against what was actually confirmed, corrects anything the draft quietly promoted from interpretation or hope to fact, and makes sure every remaining unknown is still named — before anyone treats the update as ready to send.

• Checked meeting notes — facts, interpretations, decisions and unknowns kept clearly separate (Lesson 1).
• The action log — what's been completed, what's still open, who owns it and by when (Lesson 2).
• Explicitly named unknowns — anything genuinely unresolved, stated plainly rather than smoothed over (this lesson).

A worked example: Elm & Stone's client status update

A week after Lesson 1's site meeting, Elm & Stone's lead architect owes her client a status update on the kitchen extension. Her checked meeting notes from Lesson 1 recorded the delivery delay as a confirmed fact, her own "likely a week's schedule impact" as an interpretation nobody had verified, the completion date as still undecided, and the cause of the delay as unknown. Since then, two things have moved on: the builder has confirmed the actual schedule impact is four working days, not the week she estimated aloud in the meeting, and the client has since agreed to a revised completion date once she gave him the confirmed figure. The supplier still hasn't explained why the delivery specifically slipped; her action log carries one open item for it, owned by her, due before next week's meeting.

She asks an AI assistant to draft the client update from her notes and action log. The draft reads: "The steel delivery was delayed, but the schedule has now fully absorbed the impact and the project remains on the original completion date." Checking it against her records, she finds two things wrong: the completion date did move, by four working days, not stayed the same — the draft appears to have confused "the client agreed to the new date" with "there was no impact at all" — and the delay's cause is still unconfirmed, which the draft dropped entirely rather than naming as open. She rewrites the relevant lines: "The steel delivery was delayed by five days (confirmed with the supplier). The builder has confirmed this moves the completion date by four working days, which you've agreed to. The exact cause of the delivery delay is not yet confirmed by the supplier — I'm following up and will update you by our next meeting." She sends the corrected update, with the delay's cause still openly marked as unresolved rather than smoothed away.

Accessibility notes

This lesson is text-first, with no images, audio, video or downloadable artifacts. The practice exercise's model answer sits behind a native disclosure control that is reachable and operable by keyboard and correctly announced by screen readers. The knowledge check uses native radio-button inputs with a visible question and options, and posts its result to a live status region so assistive technology announces the outcome without a page reload.

Sources and limits

This lesson synthesises the sources below into a practical learning model. It is not a security standard, legal advice or a guarantee that any particular agent design is safe.

1. Project management glossary — APM (Association for Project Management). Defines a status report as a description of where a project currently stands, issued regularly to the project team and other responsible people, stating the status of an activity, work package or whole project, often reporting the input, issues and actions from a status meeting.
2. Project management glossary — APM (Association for Project Management). Defines a progress report as a regular report to senior personnel, sponsors or stakeholders summarising a project's progress, including key events, milestones, costs and other issues.
3. AI Risk Management Framework 1.0 — NIST AI Resource Center. Frames an AI system as an engineered system that generates outputs such as predictions, recommendations or decisions — not a self-directing decision-maker.
4. LLM09:2025 Misinformation — OWASP Gen AI Security Project. Defines overreliance as placing excessive trust in AI-generated content without verifying its accuracy.
5. LLM06:2025 Excessive Agency — OWASP Gen AI Security Project. Recommends human-in-the-loop control requiring a person to approve high-impact actions before an LLM-connected system takes them.