Use ChatGPT to Turn Project Notes Into a RAID Log

Project notes tend to mix real blockers with guesses, worries, and things someone forgot to confirm. A RAID log gives each item a label, but the label is only useful when you can trace it back to the notes.

This guide uses ChatGPT with a fictional project brief. It is a documentation-based workflow with an illustrative result. No ChatGPT execution or personal test is claimed.

What you will create

You will create a Markdown RAID log with these columns: type, item, source wording, owner, next action, due date, and confidence. RAID means risks, assumptions, issues, and dependencies. The log is a review aid. It does not approve a plan or assign work automatically.

Level: Intermediate. You need access to ChatGPT file upload or a chat that accepts pasted text, plus permission to use the project notes. Use fictional or approved non-sensitive data for practice.

The fictional notes

Save this as mobile-checkout-notes.txt or paste it into ChatGPT:

Project: Mobile checkout pilot

The team wants to test a shorter checkout flow with 50 existing customers in November.

The design team has a draft flow. Engineering says the payment provider supports the required fields, but nobody has confirmed the provider configuration in the pilot account.

Legal still needs to confirm whether the consent wording is acceptable. The product manager expects legal feedback next Tuesday, but the date is not on the project calendar.

Customer support can prepare a response for failed payments. The support lead has not confirmed who will own the response during the pilot.

The pilot should use anonymized test records where possible. The notes do not say who will approve the final customer list.

The team hopes the shorter flow will improve completion. No success threshold has been agreed.

Use the prompt

Open ChatGPT and start a new chat. Use only the fictional notes or an approved project note file.
Ask ChatGPT to inspect the source and propose its categories before it writes the table.
Paste the prompt below.
Read the output against the original notes. Correct any owner, date, approval, or metric that the notes do not support.
Copy the accepted table into your project workspace only after a human reviews it.

Read only the project notes supplied for this task. Create a reviewable RAID log.

Use these definitions:
- Risk: an uncertain event that could harm the project if it happens.
- Assumption: something the plan currently treats as true but has not confirmed.
- Issue: a problem already present in the notes.
- Dependency: a person, team, system, or decision the project needs.

Do not invent owners, dates, approvals, customer numbers, metrics, legal conclusions, or technical facts. Do not turn a hope into a result. When the notes give no owner or date, write `unassigned` or `not set`.

Return:
1. A five-line source summary.
2. A Markdown table with exactly these columns: type, item, source wording, owner, next action, due date, confidence.
3. A section called `Items that need human confirmation`.
4. A section called `Questions for the next review`.

Rules for the table:
- Use only Risk, Assumption, Issue, or Dependency in the type column.
- Quote a short phrase from the notes in source wording. Do not create a quote that is not present.
- Keep the item separate from the next action.
- Use `low`, `medium`, or `high` confidence to describe how directly the notes support the classification, not how serious the item is.
- Flag the missing success threshold, the unconfirmed payment configuration, the legal consent review, the support owner, and final customer-list approval.
- Treat the expected legal feedback date as an expectation, not a confirmed deadline.

Illustrative result

A good log marks the payment configuration as an assumption, legal feedback as a dependency, and the missing support owner as an unresolved dependency. It keeps the hoped-for improvement as a risk or open question rather than reporting an improvement. This paragraph is an editor-written expected result, not captured model output.

Acceptance checks

Before you share the log, confirm that:

every row maps to a phrase in the notes
the pilot size remains 50 existing customers and the month remains November
the payment configuration is not reported as confirmed
the legal date is not presented as a calendar commitment
support ownership and customer-list approval remain unresolved
the missing success threshold appears as a question or open decision
the confidence field describes source support, not business priority

Troubleshooting

ChatGPT invents a named owner. Add Never infer a person from a department. Use unassigned. Then compare the revised row with the notes.

The table mixes risks and issues. Ask for the definition of each type beside the row and classify anything uncertain as an assumption until a human confirms it.

The source wording is not traceable. Ask for an exact short quote and remove any row whose quote cannot be found in the original notes.

The output reports a success metric. Replace it with not set unless the notes contain an agreed threshold. A hope is not a measurement.

Limits and safer use

A RAID log makes uncertainty easier to discuss. It does not validate legal advice, test a payment system, choose customers, or assign accountability. Keep personal and payment data out of a practice file. Use an approved workspace and review the current account settings before uploading business material.

For a source-linked decision table, see Compare supplier proposals with Claude.

Want one useful workflow each week? Join The Weekly Verdict.

Sources

Evidence label: Documentation-based guide with fictional input and an illustrative output. No ChatGPT execution or personal test is claimed.