---
name: raid-log
source: https://app.decimal.ai/s/raid-log@1/SKILL.md
source_sha256: a3822f710d0f
---

# 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.