Role Playbooks5 min read

Turn a Project Status Update Into a Decision Brief With AI

Use AI to restructure approved project notes into a decision-ready brief—without inventing owners, dates, status or evidence.

Bokili EditorialPublished September 9, 2026· Verified September 9, 2026

Project notes pass through a verification gate into a decision brief with evidence, decision, owner and due-date symbols.

A weekly project update can be accurate and still fail its reader. It may list completed tasks, open risks and next steps without saying what a sponsor must decide. AI can help turn approved project notes into a decision brief, but only if the source boundary stays visible and the project manager verifies every material field. The goal is not a more polished summary. It is a shorter path from evidence to a timely, owned decision.

UK Government Project Delivery guidance makes that purpose explicit: reporting should show status and outlook against the baseline, and requests for advice, direction or decisions should be clear. The project delivery functional standard adds that reports should be factual and realistic, covering progress, delivery confidence, risks and the direction required. Those are useful design constraints for an AI-assisted workflow because they define what the brief must help a reader do.

Keep the authority human

Ask AI to propose the structure and expose gaps. The project manager remains responsible for the evidence, status judgement, named owners and decision request.

Use the CLEAR decision brief

CLEAR: five fields that earn space

Change

What materially changed since the last agreed baseline or report? Omit routine activity unless it alters the outlook.

Level of impact

State the effect on scope, schedule, cost, benefit or risk. Separate a current fact from a forecast.

Evidence

Point to the approved note, register, milestone or measure that supports the statement. Mark missing or conflicting evidence.

Action and owner

Record the response, accountable owner and due date only when the source contains them. Otherwise show the gap.

Required decision

Ask one explicit question, name the decision owner and state when the answer is needed. Include viable options and conditions when available.

Prepare the source packet before prompting

Do not pour an entire project workspace into a general chat. Select the smallest approved packet that can support the report: the current baseline, the latest milestone position, the live risk or issue entries, recorded changes and the previous decision. Remove personal or sensitive material that the approved tool should not receive. Label every extract with its date and source. If two sources disagree, keep both and ask the AI to flag the conflict rather than silently choose.

From status notes to a decision request

1
Lock the reporting cut-off
Write the period covered and the baseline being used. A late note belongs in the next cycle unless it changes an urgent decision.
2
Extract candidate changes
Ask for changes to outcome, milestone, risk, issue or dependency. Tell the model to ignore routine activity.
3
Build CLEAR fields
For each candidate, request impact, evidence, response, owner, due date and required decision. Missing fields must remain visibly missing.
4
Challenge the draft
Compare claims with their sources. Check dates, owners, figures, status labels and any forecast separately.
5
Send the smallest useful brief
Put the decision request first. Attach detail or link to governed records instead of reproducing every note.

A prompt that preserves uncertainty

Reading is a start. Practice makes it stick.

Start learning

Draft a decision brief from approved notes

Using only the approved project notes below, draft a decision brief for the named decision owner. Start with the exact decision required and the date needed. Then use CLEAR: Change, Level of impact, Evidence, Action and owner, Required decision. Distinguish current facts from forecasts. Do not infer an owner, date, status or number. Mark any missing or conflicting field as ‘needs confirmation’. List the source label beside every material claim. End with no more than three viable options and their stated conditions.

Decision required: approve a two-week pilot extension by 14 September. Change: integration testing is three days behind the agreed milestone. Level of impact: forecast only; launch confidence is reduced if the defect remains open. Evidence: test log, 8 September; milestone register, version 6. Action: defect triage is recorded, but the accountable owner needs confirmation. Options: extend the pilot, reduce the pilot scope, or hold the current date subject to the stated acceptance condition.

The example is illustrative. A real brief must retain the organisation’s actual source labels, approval rules and status definitions.

Worked example: a CRM rollout

A project manager receives six notes: training is complete, a data-migration defect remains open, the supplier has proposed a workaround, the pilot date is unchanged, one regional lead asks for an extension and the risk register has not been updated. A conventional AI summary might praise progress and recommend delaying the pilot. That oversteps the evidence. The notes do not show an approved delay, an agreed owner for the defect or the impact of the workaround.

	Activity summary	Decision brief
Opening	Training finished and testing continues.	Decision needed: keep, narrow or extend the pilot after the unresolved migration defect.
Evidence	Several teams reported concerns.	Test log dated 8 September records one open defect; regional extension request is a separate source.
Ownership	The supplier will fix the issue.	Supplier proposed a workaround; accountable owner needs confirmation.
Uncertainty	Pilot may be delayed.	Schedule impact is unconfirmed until triage and risk review are complete.

The second version is less fluent and more useful. It makes the decision visible, separates evidence from forecast and gives the sponsor a precise reason to respond. Government project data guidance reinforces the discipline behind this format: accurate, timely and consistent data supports decision-making, while risk records need an owner, response owner and due date for traceability.

Verify the brief before it travels

The 90-second decision-brief check

The requested decision is explicit, owned and time-bound.
Every material change is compared with the correct baseline.
Facts, forecasts, assumptions and recommendations are visibly different.
Dates, figures, owners and status labels match the governed source.
Conditions, dependencies and dissenting evidence remain attached.
Missing information is marked rather than guessed.
The brief contains only information appropriate for its recipients.

Turn one update into a decision brief

Choose one safe project update that contains a real request for direction.
Copy only the approved baseline, latest change and relevant risk or issue entry.
Run the CLEAR prompt in an approved AI tool.
Verify one date, one owner, one status and one forecast against the source.
Delete routine activity that does not change the decision.
Ask the intended reader whether the request and options are clear.

The practical boundary

This workflow does not replace project controls, direct conversations or formal approvals. Reporting guidance says reports should prompt action, not substitute for managing the work. Use AI to organise the evidence and reveal gaps; record the final decision in the organisation’s governed system. For adjacent habits, see Bokili’s Teams decision register, prompt experiment template and scale, hold or stop pilot gate.