RAID log — triage inputs into four strictly separate buckets

What this does

Given raw project material — the running notes from a meeting, a messy chat thread, a weekly update someone pasted in — this sorts each item into one of four buckets and fills the fields that bucket requires. The whole value is keeping the buckets clean: the same word ("the vendor might miss the date") lands in a different bucket depending on whether it may happen or is already happening, and each bucket carries different fields.

Output is four labeled sections, in this order: Risks, Assumptions, Issues, Dependencies. Each item is one row. Empty buckets are shown with "(none)" rather than dropped, so the reader can see the bucket was considered.

The four buckets

Decide the bucket by the item's tense and source, then fill only that bucket's fields.

Risk — something that MAY happen. Future, uncertain. If it has not happened yet and might not, it is a Risk. Required fields:

• likelihood (low / medium / high)
• impact (low / medium / high)
• mitigation (what would reduce the likelihood or the impact)
• owner (who watches it)

Assumption — something being treated as true but not confirmed. A belief the plan rests on. If it turns out false, the plan shifts. Required fields:

• validation (how someone would confirm or disprove it)
• validate-by (the date by which it should be checked)

Issue — a problem happening RIGHT NOW. Already real, already biting. Required fields:

• action (the next step to resolve it)
• owner (who is on it)

An Issue is never given a likelihood or an impact score — those belong to Risks only. Scoring an Issue like a Risk is the most common mistake; do not do it.

Dependency — something needed from an outside party. A hand-off from another team, vendor, or person you do not control. Required fields:

• party (who owes it)
• needed-by (the date you need it)

The one rule that decides most items

Already happening → Issue. Might happen → Risk. Never file a materialized problem as a Risk, and never file a hypothetical as an Issue.

• "The staging server is down and blocking QA" → Issue (it is down now). Action + owner.

No likelihood, no impact score.

• "The staging server could go down during the launch" → Risk (it might). Likelihood,

impact, mitigation, owner.

Two more discriminators for the trickier items:

• Something you are taking on faith (a number, a capacity, a date someone gave you but

did not commit to) → Assumption, with a way to check it and a check-by date. It is not a Risk just because it is uncertain — a Risk is an event that may occur; an Assumption is a belief you are relying on.

• Something you are waiting on from outside the team → Dependency, naming the party

and the needed-by date. Do not bury it as a Risk ("they might be late") — file the dependency itself; lateness can be a separate Risk if worth tracking.

Worked example

Input: "Deploy went out fine. The prod DB is running hot right now — queries timing out, nobody's on it yet. We're assuming the vendor's new API can handle 10k requests/min but haven't tested it. If the marketing push lands before the caching work, we could get overwhelmed. Legal still owes us the reviewed terms before we can launch — need them by the 15th."

Risks | item | likelihood | impact | mitigation | owner | |---|---|---|---|---| | Marketing push lands before caching work is done, overwhelming the system | medium | high | Sequence the caching work ahead of the push, or hold the push | (unassigned) |

Assumptions | item | validation | validate-by | |---|---|---| | The vendor's new API can handle 10k requests/min | Load-test the API against 10k req/min | (before launch) |

Issues | item | action | owner | |---|---|---| | Prod DB running hot, queries timing out | Investigate and stabilize the DB | (unassigned) |

Dependencies | item | party | needed-by | |---|---|---| | Reviewed terms required before launch | Legal | the 15th |

Note the "running hot right now" item is an Issue with no likelihood/impact, while the "could get overwhelmed" item is a Risk with both. Same system, different tense, different bucket.

When a field is not stated

Do not invent owners, dates, or scores. Write (unassigned) for a missing owner and (no date) for a missing date. For a Risk missing a likelihood or impact, use your best read from the input but keep it to low/medium/high — never leave a Risk unscored, since the score is the point of filing it as a Risk.